axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Boot/SPAD package syntax


From: Gabriel Dos Reis
Subject: Re: [Axiom-developer] Boot/SPAD package syntax
Date: Tue, 5 Jun 2007 15:59:50 -0500 (CDT)

On Tue, 5 Jun 2007, Stephen Wilson wrote:

| Gabriel Dos Reis <address@hidden> writes:
| 
| > On Tue, 5 Jun 2007, Stephen Wilson wrote:
| > 
| > | I think I have a picture now. I perceive there to be three boots. Old,
| > | New, and New-New (your improved boot).
| > 
| > That picture might be inaccurate -- ask Tim about all the gory details. :-)
| 
| True, true.  In time I hope to get a complete picture.
| 
| [...]
| > C does not have asm.  C++ does.
| 
| I just had to check. Geeze, details, details :)

I've been reading too many C and C++ technical details for over a decade :-)

[...]

| As I sit on the Lisp side of things this does not jive with a boot
| implementation directly.  Perhaps it is of some interest to you regardless.
| 
| With this comes the blatent assumption that calling out to the Lisp
| level requires detailed understanding of how SPAD entities are
| represented, and how the underlying Lisp image is designed. 
| 
| I am considering the mechainics involved in treating domains and
| categories as well-defined lisp objects, complete with api's and
| protocals to manage their runtime manipulation, among other things.

Yes, this is part of what I have been calling The Axiom Virtual Machine.
I have not sent a complete proposal to the list, but it is one I'm working 
on.  The specification includes things like abstract specification for 
categories, domains, packages, and Spad typed abstract syntax tree for Spad
programs, along with runtime APIs -- the Axiom Virtual Machine Instruction
Set.   It will provides specification for the layout of the 
compilation file for a Spad program -- much like the specification of a JVM
class file.

[...]

| > | Yes.  I will modify the parser to emit a message on encountering the
| > | construct.
| > 
| > Exactly what I would have done.
| 
| I will let you know if I encounter a dependence on the package-call
| operator in the extant code.

Many thanks!

-- Gaby




reply via email to

[Prev in Thread] Current Thread [Next in Thread]