On Tue, 5 Jun 2007, Stephen Wilson wrote: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > Stephen Wilson <[EMAIL PROTECTED]> writes: | > | > | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | > | | > | > Stephen Wilson <[EMAIL PROTECTED]> 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 mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
