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

[Stephen Wilson]

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 :)

> Both Boot and Spad have the translation time )lisp system command
> to excute Lisp codes, but that does not include runtime codes.
> 
> New Boot (Shoe) also has the esclamation (!) character as escape to Lisp:
> You can include arbitrary non-toplevel Lisp forms (as you would include
> arbitrary asm in C++) through the escape character.  

Ok. Thanks.

> In "pure" Spad, "package calling" Lisp is the only effective means of going
> at the assembly language level.  It is very useful occasionally.  For example,
> it is used for SExpression.  I've used it to provide a Spad domain view
> on top of the s-expression abstract syntax tree produced by the old
> compiler.  I'm writing a new library for the new compiler.

I would like to describe a relatively new idea (for me).  It will
likely take a long time to see a prototype.

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.

Instead of a package call to Lisp, Im considering the possibility of
defining SPAD functions in Lisp, and making them available as domain
exports `transparently'.

Given a prototype:

 (ensure-domain-export <export-name> <domain-obj> <axiom-type-specifier>
    ...)

The basic idea would be to enrich the system with a new export
(labeled with the `export-designator' <export-name>) for the domain
object <domain-obj>, satisfying a certain type represented as the
object <axiom-type-specifier>.

The consequence is that this appears as a `native' spad export.  The
<axiom-type-specifier> ensures that call sites are staticly type
checked.  Types of return values would be dynamically asserted (this
is a low-level interface. Trust the programmer).

One might find the name ENSURE-DOMAIN-EXPORT reminiscent of those
provided by the CLOS MOP.  This is intentional.

I feel that SPAD should have an (easily extensible) set of primitive
domains and categories upon which all others ultimately derive.  As in
most programming languages, there is no way to define such objects
directly.  This is one approach which I suspect alleviates the need
for escape to Lisp.

[...]
> | 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.


Cheers,
Steve