axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Boot


From: root
Subject: Re: [Axiom-developer] Boot
Date: Mon, 2 Oct 2006 13:05:00 -0400

> | the new ASDF facility will make makefiles into one-liners.
> 
> this makefile stuff does not require writing the whole interpreter in
> Lisp. 

The makefile stuff and lisp are independent. But lisp now has the
proper facilities for system building that work directly. This
eliminates the need for makefile stanzas related to compiling
and loading lisp files. Many of the makefile stanzas simply
disappear because they are no longer necessary.

> | the new UFFI facility will make external functions portable.
> 
> Boot being a syntactic sugar over Lisp, this UFFI stuff clearly cannot
> be an argument againt Boot.
> 
> | the McCLIM facility will make embedded graphics possible and portable.
> 
> Ditto.
> 
> | CLOS will make the interpreter much more general and easier to change.
> 
> Ditto.
> 
> | CLSQL will allow the use of a real database backend.
> 
> Ditto.

In order to use these facilities the boot language would have to be
extended or redefined in various ways. For instance, CLSQL statements
cannot be used from the boot level because CLSQL uses the square bracket
notation. Boot uses the same notation with different meaning. CLSQL uses
the lisp reader-macro facility to redefine the meaning of the square
bracket character which immediately breaks boot.

> 
> | SLIME will make emacs know all about axiom.
> 
> This has nothing to do with Boot.

If the interpreter is in boot the SLIME environment would need to 
know how to handle boot syntax. But SLIME knows all about lisp
directly and is a useful support environment for lisp code.

> 
> It looks to me that none of the reasons you advance speaks for
> removing Boot.
> 

There is no reason that requires the removal of boot.
There are reasons that favor the removal of boot.


BOOT requires that you insert a translation step into every
file you process which causes you to require ADDITIONAL stanzas in
the makefiles. 

Boot translation takes time during system build which can be eliminated.

Boot inserts the translation step between you and the lisp top-level
loop, making debugging "one step removed".

Boot is written in boot. Which means that if you change it you
have to re-translate the lisp code used to bootstrap it and re-insert
it into the files (see btincl2.boot for instance).

Boot adds to the total amount of code that needs to be maintained,
making the support task harder.

Boot constructs translate into inefficient, time and space poor
list-based code constructs. 



Oh, and there is an unmentioned problem with boot. The boot parser
is fairly sensitive. You'll notice that in src/interp/bootlex.lisp
there is a line that reads:

 (format out-stream ";;;Boot translation finished for ~a~%")

This line is there because if the boot translation fails it quietly
truncates the translated lisp output. The old makefiles used to run
a check for this string after each translation. I forgot to include
this check as part of the recreated Makefiles. This will only become
apparent when/if people start changing boot code. We will have to again
automate the check to ensure that we don't quietly break the world.
This isn't apparent (yet) because no-one codes in boot.



Frankly, I'm just astonished. Boot is a language with 0 users, two
undocumented implementations, and restrictive syntax and semantics
which produces slow, inefficient list-based code and increases build
time.  It has not one benefit except that you don't need to understand
lisp syntax for a very limited set of constructs but you must
understand lisp to use it.

Make it into a real, documented, standalone language or kill it.
I have no plans to work to make it real, documented, or standalone.
I'll leave that for someone else.

t







reply via email to

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