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

[Gabriel Dos Reis]

On Tue, 5 Jun 2007, Stephen Wilson wrote:

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

OK.
We are back to my earlier point: When you say Boot, you need to qualify it.

FYI, the boottocl defined src/interp is scheduled for death (as is depsys).  
The plan is to migrate to bootsys.  See the comment in the source codes. 

| > | In
| > | particular, the Boot which translates the current Boot code.  
| > 
| > What do you think bootsys is used for?
| 
| To bootstrap the system. 

Good.

| As you know, it works with the boot flavor in src/boot.  

And some part of src/interp too.

[...]

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

Looks to me that you're not interested in one.

Because the original message had several of them.

[...]

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

Time will come.

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

That is not what I'm saying.

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

I know SPAD has package -- see my other mail for what I meant by
"package-call", which is not my invention but that of the inventors of both
the Spad and Boot languages.

| These do not relate to Lisp packages directly. 

No, but the notion of "package-call" is that of selecting a symbol from a
specific place.  That notion is the same in both Lisp and Spad.

| > Lisp i5As 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.

Thanks for repeating back what I said.

| What is a Boot package?  

A Boot package is no different from Lisp package: a name space.

Old Boot assumes that everything goes into the BOOTTRAN package.

New Boot assumes that people are responsible of pushing into the package
the want.

| How do you create one from Boot? 

I believe in CLTLx, a reference to a package creates that package if it 
does not already exist.  Boot uses that semantics.

| I suspect boot packages are just lisp packages.

Boot is used to *implement Axiom*.  Yes, it is language that translates
to Lisp.  

| 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?

The Ada-style FOO'BAR was considered obsolete, I believe, for Spad (and 
later for Old Old Boot).

| I am primarily interested in the SPAD case.

In the specific case of Spad, that specific construct can go away.

|  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,

No more dangerous than pretend.

What we need is not to prevent people to call Lisp -- they will, and there 
are legitimate cases where one needs to access the assembly-language
(currently only Lisp).  What we need is an assembly-indepedent interface,

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

Since the same parser is used to parse Old Boot, you'll also need more than
superficial examination that no Boot codes uses it.

-- Gaby