--- Bill Page <[EMAIL PROTECTED]> wrote:
> I think this is not an accurate description of the situation since
> Boot is written in Lisp and it is *part* of Axiom. In other words no
> matter what we do, Axiom is written in Lisp. Period.
Currently, true. As we have discussed earlier, Lisp is regarded by
some as a ghetto in the software world and thus a possible intellectual
"dead end." (I don't think it is, but that ground has been covered.)
I had taken that as a desire on the part of some people to shift
entirely off of Lisp to something else (Aldor, for example.)
> This is a question of *how* to use Lisp in Axiom, i.e. whether to use
> Lisp to first implement an intermediate application-specific
> higher-level language (Boot) and then use it in turn to implement
> Axiom (Spad and Interpreter). Note: this is a development strategy
> also used in some other large software projects besides Axiom. Or
> whether to dispense with the intermediate language and write
> everything at the same level.
To me, the logic should work like this:
A new programming language should only be introduced when the
expressive power gained by implementing the new language is sufficient
to counteract the cost of the inevitable definition work, programmer
learning curves, compiler debugging cycles, and ongoing maintainance
involved with the creation and use of the new language.
Lisp is a language with a stable definition, considerable expressive
power, and several high quality free implementations. It also has a
mass of useful utility libraries, although I concede it is missing a
few key ones such as a native graphics toolkit (McCLIM isn't quite
there yet).
My own guess (and it is just a guess, I have no way of quantifying
this) is that there are only three situations in Axiom which justify
the introduction of a language other than Lisp.
1) Interactive mathematical language (B-natural) - make the
interactive environment feel as much like "human" mathematics as is
practical. If you don't do this, you don't get end users.
2) Mathematical library programming. This task is likely to involve
such a large total percentage of the effort involved in creating Axiom
that the effort required to create a language tuned to support it will
be more than paid back in code quality and productivity, in spite of
the extra work it requires. Hence, SPAD or Aldor.
3) Proof languages - not as native languages, but I can see being able
to "speak" the various languages of proof engines. Proof engines are
highly non-trivial and confirming results in multiple engines only adds
to the credibility of a solution - hence flexibility is worth some
effort. Being demonstrably correct is probably the single biggest
chance Axiom has of being something more than "just another CAS."
I suppose you could regard LaTeX as a forth case, if you wanted to.
> Writing everything at the same level is a reversal of one of the
> design decisions made by the original Axiom developers. I think this
> could be cited as grounds for not applying the name "Axiom" to this
> approach.
The intent of every branch I am aware of is to have at least two levels
- one for the Algebra and one for the supporting layers. Tim has
related to us some of the history of the Lisp vs. Boot question in the
original project, IIRC - so we're carrying on an age old tradition in
that respect ;-).
> I agree that having defined a sufficiently general higher-level
> intermediate language (as Boot, arguably nearly is) it is in
> principle possible to imagine eliminating the need for the language
> in which it was originally written (Lisp) at least after you first
> solve the bootstrap problem. This is what happened with the most of
> the ML languages for example. Perhaps this is the direction in which
> Gaby has imagined taking Boot.
If I understand correctly, Aldor does not in fact require Lisp at all?
> But if one were really inclined to make this rather big step, then I
> think one would be much better off at the level of Spad, rather than
> Boot. To do this it would be necessary to improve Spad sufficiently
> that it could take over the role of Boot. But in effect we already
> have this! It's name is Aldor. And as far as I can see that is
> exactly the direction in which the original Axiom project was headed.
Then, we also have the 30 year horizon goals that were the beginning of
the open source Axiom project.
> But realistically in the short to medium term I do not see any
> practical way to really abandon Lisp as fundamental to Axiom. At best
> one might hope to do (as Gaby outlined in his slides) would be to
> define a much reduced and streamlined subset of Lisp whose specific
> purpose is was to efficiently implement Axiom. This is (more or less)
> exactly what NAG was attempting to do with the use of CCL in its
> commercial version of Axiom.
That's just it - some of us want to do that, and some of us want to
embrace Lisp. IIRC it sounded like even in the original commercial
Axiom team there was disagreement about how to handle this, although
I'll have to go back and re-read the emails describing it.
Cheers,
CY
____________________________________________________________________________________Ready
for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
