[Top][All Lists]

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

RE: [Axiom-developer] RE: Boot vs. Lisp

From: Weiss, Juergen
Subject: RE: [Axiom-developer] RE: Boot vs. Lisp
Date: Wed, 2 Nov 2005 09:57:40 +0100


I want to make a few comments to the discussion. Some were
in part already made in a recent mail by Bill Page.

1. Lisp versus BOOT versus SPAD

What's the difference between Lisp and BOOT? In a way, it's
similar to Lisp and Rlisp, the language in which Reduce is
written. And there are probably a quite a few other examples as 
well. It's just a different syntax (less parentheses if you like)
and different control structures (loops, if-then-else, defining
functions etc.). The functions you can call are the 
functions of the Lisp system, the functions you define get
added to the Lisp system. As datatypes you have the Lisp
datatypes (no syntax for structures yet). So in a way,
it's just a different syntax for Lisp.

2. BOOT versus SPAD

As above, it's similar to Rlisp and the Algebra mode of Reduce.
The syntax and the control structures of BOOT and SPAD and
the Axiom interpreter are the same. But BOOT just does not
have types (categories, domains, etc), just the Lisp types. 

3. Parsing BOOT code

The parser for SPAD code is able to parse BOOT code as well --
which is not too surprising after point 2 above. You can
build Axiom with it -- after a few cosmetic changes in syntax
in a few more recent files written in BOOT. This parser is
equally capable of parsing the interpreter input (modulo rules
to be fair). The parser has certain deficiencies (for example
the poor error messages in the compiler showing lisp code). 
This parser is written with the help of a parser generator
(meta). There is another parser for boot code in the src/boot
directory (always wondered, why it exists). Then there is parser
which is used for the Axiom interpreter (src/interp/pf2* files
and others). It is capable of parsing rules.

4. Destructuring setq and destructuring comparisons

One of the highlights in BOOT is the possibility
to use destructuring setqs and destructuring comparisons.
This is extremly handy. Some random examples:

  for [[.,arg], :.] in singles while null tuple repeat
    if arg is ['Tuple,.] then tuple := arg

  a is [=op,b,t1] =>

Without this feature the code will get almost unintelligible.
And this feature is used in almost every line of code.

5. My conclusions

a. I do not see BOOT as an hindrance to new contributors.
   Without a certain knowlegde of the interpreter and
   compiler language and Lisp contributions to the
   interpreter will not be possible. With the knowledge
   of the interpreter and compiler language you know
   the control structures of BOOT. There is nothing
   left to learn. With the usage of BOOT, one could 
   even argue that Lisp knowledge would be less important.

b. An automatic or semiautomatic translation of BOOT to
   Lisp as done in Volume 5 of the Axiom book is not
   very helpful. Even if you fix most of the prog, progn,
   seq etc. by hand, the loss of the destructuring
   features makes the code an order of magnitude harder
   to understand. Without a complete rewrite of the
   Axiom interpreter from scratch (not a function by
   function or module by module replacement) with a 
   more modern Lisp like look and feel (defstruct, more
   functional programming style etc), I think we can
   not get rid of BOOT without losing the maintainability
   of the code.

c. If we went for a total rewrite of the code, and at that
   time the licencing problems with A# were resolved, we
   should certainly consider reimplementing the interpreter
   in A#. Then we had only one language for the whole
   But I do not think, that a total rewrite is a viable 
   option with the current developer base and the current 
   developer model. At the current development speed it
   would take maybe 5 years or longer. And success would not
   be sure.


Juergen Weiss

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

reply via email to

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