axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Axiom-developer] Boot


From: Weiss, Juergen
Subject: RE: [Axiom-developer] Boot
Date: Mon, 2 Oct 2006 15:17:01 +0200

>From looking at the source and some information I got over the years,
I think, at some time, there was the idea to get rid of the old
SPAD compiler (which contains a parser for boot, spad and the
interpreter language). 

Therefore a new shoe boot parser in the boot directory was written,
and a new parser for the interpreter (which is in use). The new compiler
never
happened and finally aldor (a#) was developed. 

So we have two parsers for boot and two parsers for the
interpreter language.

There is actually a grammar file, which kind of defines the old parser
language: fnewmeta.meta

About the boot ``language''. We had this discussion before: it really
is not a new language at all, just another syntax for lisp. It has
really
neat features for destructuring and pattern matching. I would assume
that 
anyone who knows lisp get hold of the syntax in an hour or two. Bill
Page
and I argued in favor of boot for the time being, Tim Daly in rewriting
everything in lisp. I just think, that as long as lists are the main
data structure for the interpreter and the compiler, the boot syntax is
really handy. A total rewrite in lisp with defstruct et al. of the
whole system is too ambitious for the number of people contributing.
Besides, for
a total rewrite one should consider other alternatives as well (aldor,
....).

Regards

Juergen Weiss

Juergen Weiss     | Universitaet Mainz, Zentrum fuer Datenverarbeitung,
address@hidden| 55099 Mainz, Tel: +49(6131)39-26361, FAX:
+49(6131)39-26407
 

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden
>  On Behalf Of Gabriel Dos Reis
> Sent: Monday, October 02, 2006 8:50 AM
> To: CY
> Cc: address@hidden
> Subject: Re: [Axiom-developer] Boot
> 
> CY <address@hidden> writes:
> 
> [...]
> 
> | > you'll notice that the makefile in the src/boot directory 
> explicitly
> | > translates using the BOOTSYS image which contains the 
> 'shoe' parser.
> | > the makefile in the src/interp directory explicitly 
> translates using
> | > the DEPSYS image which only contains interpreted lisp files from
> | > the interp directory and is NOT the same as the boot/shoe version.
> | 
> | Scary.
> 
> :-)
> 
> | > rather than referring to them both as boot perhaps we should call
> | > the one in the src/boot directory 'shoe', following 
> bill's convention.
> | 
> | I suppose I should know better than to ask, but since the 
> eventual goal is to 
> | move the interp to Lisp anyway would a viable alternative 
> be to "decode via 
> | rewrite?" 
> 
> The more I read the interpreter code, the more I become 
> convinced that 
> Boot should stay.  It simplifies many lots of logic; the benefits of
> removing it does not seem to me to outweight the cost and the result.
> 
> [...]
> 
> |                                                             
>    For example 
> | (and this might be crazy, it's just a thought) wouldn't it 
> be possible to use 
> | packages and the use/import/shadow concepts to handle some 
> issues related to 
> | things like subdomains? 
> 
> Funny you should mention that.  I was starring at the i-*.boot files
> and was wondering why on the earth all knowledge had to be "hardcoded"
> into the interpret instead of being abstracted into a library...
> 
> [...]
> 
> | Eeek.  Shouldn't we be specifying what the language SHOULD 
> be, and then 
> | re-merging the code into the new framework?
> 
> yes, but we need data, i.e. what we want the language to achieve; for
> the moment, the existing code provide such data.  I suspect now, we
> know what we would like to improve, what did not work, and what is
> simply broken idea.
> 
> -- Gaby
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]