Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > 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.
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 _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
