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: Stephen Wilson
Subject: Re: [Axiom-developer] Boot/SPAD package syntax
Date: 05 Jun 2007 02:58:09 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Gabriel Dos Reis <address@hidden> writes:

> Stephen Wilson <address@hidden> writes:
> 
> | Greetings,
> | 
> | I stumbled upon a curious facility of Boot and SPAD this evening.  I
> | do not recall, nor can I find, a reference to this in the list
> | archives or in any documentation.  Please correct me if I am wrong.
> 
> Since we have at least two versions of Boot around, you need to qualify
> your Boot by either "old" or "new" or variations thereof.

When I say Boot, I mean the Boot which is used in Axiom.  In
particular, the Boot which translates the current Boot code.  Other
variations are effectively mythical to me.  I guess this is what you
qualify as "old"?

> 
> | The facility is w.r.t identifiers.  An identifier such as FOO'BAR is
> | interpreted as meaning the symbol BAR in the package FOO.  Other
> | identifiers, such as 'FOO or FOO' do not communicate such a meaning.
> 
> That is old old syntax. Newer syntax in old Boot is FOO::BAR -- but it 
> may require parenthesis in most cases because of the precedence of
> :: qhich does not make FOO::BAR a primary.

Superficial examination does not suggest that this syntax is used
anywhere in current boot or spad code.

Regardless of syntax, I am more interested in the semantics of the
construct.

> New Boot (in src/boot) has gotten same syntax (::) recently (added by me).

Ok.  This is in gdr-sandbox, no?

> | My opinion is that this is unused cruft which has no discernible
> | application.  In fact, it theoretically results in the generation of
> | non-portable code.  For example, several popular Lisp implementations
> | have introduced the notion of `package locks' to prevent against
> | unintended alteration of package symbols.  The identifier CL'FOO
> | results in FOO being interned in the COMMON-LISP package, which would
> | violate such a lock.  There are other examples.
> 
> Those are *bugs in Axiom* source code -- there are plenty of those
> around. 

Not quite following.  There is nothing to suggest to me that SPAD as a
language defines identifiers such as CL'FOO as being invalid in the
same way as, say, C++ defines identifiers which start with an
underscore to be reserved names for use by the implementation.

Given the lack of specification, and given the lack of use of such a
feature, these are not bugs in Axiom by any stretch.

> Even if you remove the syntax CL'FOO, you'll find that existing
> Axiom codes uses other things like restart, etc.

I know axiom calls Lisp from SPAD and Boot directly.  As far as Boot
goes, I dont have much interest in its semantics.  In SPAD however, I
am generally concerned with the ease with which one can bypass the
typesystem and call arbitrary Lisp code.


> | I am curious if anyone has noticed this facility and/or sees a potential
> | use for it.
> 
> I use the syntax FOO::BAR, but not FOO'BAR, for "package-call".
> New Boot treats FOO'BAR as a "single" identifier.

Ok, a "package-call" is a Lisp concept.  As far as I know neither Boot
nor SPAD admit the concept of a package.

Are there other operations in Boot which deal with packages? How can
one define a package in Boot? (by "in Boot" I mean "in Boot", not by
punting to Lisp with a MAKE_-PACKAGE('FOO)). 

I am interested in how this feature integrates with Boot, but also
lets not forget SPAD.


Thanks,
Steve





reply via email to

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