[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Boot/SPAD package syntax
From: |
Gabriel Dos Reis |
Subject: |
Re: [Axiom-developer] Boot/SPAD package syntax |
Date: |
Tue, 5 Jun 2007 10:37:00 -0500 (CDT) |
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
- [Axiom-developer] Boot/SPAD package syntax, Stephen Wilson, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Gabriel Dos Reis, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Stephen Wilson, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Ralf Hemmecke, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Stephen Wilson, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Gabriel Dos Reis, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Stephen Wilson, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Gabriel Dos Reis, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Gabriel Dos Reis, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Stephen Wilson, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax,
Gabriel Dos Reis <=
- Re: [Axiom-developer] Boot/SPAD package syntax, Stephen Wilson, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Gabriel Dos Reis, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Stephen Wilson, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Gabriel Dos Reis, 2007/06/05
- Re: [Axiom-developer] Boot/SPAD package syntax, Stephen Wilson, 2007/06/05