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

[Stephen Wilson]

Gabriel Dos Reis <address@hidden> writes:

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

I think I have a picture now. I perceive there to be three boots. Old,
New, and New-New (your improved boot).

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

I know you want this to occur.

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

I was interested in a construct which I thought might be a
little-known feature.  I wanted to know what use it had, in the
contexts of SPAD and Boot.  I was clear in indicating that it can be
interpeted is a simple callout to Lisp.  

Regardless, I now understand the function of the operator. I _do_
appreciate you lending your insight.


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

The only other interpretation I can come to by rereading the
discussion is that CL'FOO (or CL::FOO) is effectively an escape syntax
into Lisp, and as such Boot does not define semantics for such
constructs.  Similar to C's asm.

If this is correct, my appologies.  I was under some misunderstanding
that Boot was going to abstract away such things.  I really did think
it was possible that Boot had its own notion of `package', not
necessarily conincident with Lisp's.

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

If anything, I would highly recommend Boot be updated to emit ANSI
Common Lisp.

[...]
> | I am primarily interested in the SPAD case.
> 
> In the specific case of Spad, that specific construct can go away.

Ok.  I thought as much.

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

Yep. I agree in principle.


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

Yes.  I will modify the parser to emit a message on encountering the
construct.


Thanks,
Steve