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

[Stephen Wilson]

Gabriel Dos Reis <address@hidden> writes:

> Stephen Wilson <address@hidden> writes:
> 
> | 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. 
> 
> Why do you think I meant something else?

The basic point is that, by the time AXIOMsys is generated, there is a
function BOOTTRAN::BOOTTOCL.  AFAIK, there are two such functions with
the same name defined in src/boot/ptyout.boot.pamphlet and
src/interp/util.lisp.pamphlet.  The latter version is the one which
lives in an Axiom image, and also depsys.  Thats the boot Im refering
to.
> 
> | In
> | particular, the Boot which translates the current Boot code.  
> 
> What do you think bootsys is used for?

To bootstrap the system.  As you know, it works with the boot flavor
in src/boot.  The majority of the code is translated by depsys.

> 
> | Other variations are effectively mythical to me.  
> 
> I can see that.
> 
> | I guess this is what you qualify as "old"?
> 
> No.
> 
> New Boot is the one from src/boot.
> Old Boot is done by depsys.

Ok. 

> 
> [...]
> 
> | Regardless of syntax, I am more interested in the semantics of the
> | construct.
> 
> If you don't like my anseer you're out of luck.

Its not that I dont like your answer, its just that I havent gotten
one yet.

> 
> | > New Boot (in src/boot) has gotten same syntax (::) recently (added by me).
> | 
> | Ok.  This is in gdr-sandbox, no?
> 
> The (::) syntax was already in Old Boot.
> It was added to build-improvements.

Ok, thanks.

> 
> | > | 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.
> 
> Axiom source code == the collection source code that makes up the
>     Axiom interpreter or compiler.
> 

Right.  Not sure I get your point. 

> | Given the lack of specification, and given the lack of use of such a
> | feature, these are not bugs in Axiom by any stretch.
> 
> In this specific case, the bugs I've came across happen to be in the
> manually written Lisp parts, like restart -- I believe I already
> mentioned that.

Ok, I asked what the package call operator ' (or ::) means, and now
your just saying that if CL'FOO has undefined behaviour its a bug in
Axiom as opposed to a bug in the language semantics of Boot (or SPAD
for that matter).

Not sure how the bug count in manually typed bootified lisp code
relates to this (I assume you are refering to the Lisp code written
directly in Boot by typing something like CONS(x, y)).  After all, we
are talking about a Boot construct primarily (that it happens to map
to a Lisp construct is beside the point).

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

SPAD has packages as Ralf pointed out.  These do not relate to Lisp
packages directly.  The *only* interpretation of a Boot or Spad
"package-call" via ' or :: that I can see relates to the native Lisp
notion.

>From what I can see, Boot gives you a surface syntax to interact with
the Lisp package system.

Could you give a breif example of what constitues a Boot package and
the operations defined on it?
 
> | Are there other operations in Boot which deal with packages? How can
> | one define a package in Boot?
> 
> Lisp is part of New Boot through the espace (!) character.
> Names in all caps are defined to correspond to their equivalent
> in Lisp.  If you want to push into an existing package, you say
> 
>    )package "FOO"

This appears to be surface syntax for (IN-PACKAGE "FOO").  It does not
define a package.

What is a Boot package?  How do you create one from Boot? 

I suspect boot packages are just lisp packages.


Note too, this issue is also of importance for the SPAD language.
What does FOO'BAR mean in SPAD?  How does it realate to other
constructs in the language?

I am primarily interested in the SPAD case.  I was hoping for some
illustration of how the construct is put to use in SPAD.  As I feel
direct Lisp callouts from SPAD are a dangerous thing, I need some
convincing that this construct is useful/necessary.  As I mentioned,
it would seem the construct is unused, and thus support could be
easily removed from the system.

Thanks,
Steve