On October 22, 2005 7:12 PM C Y wrote:
>
> --- Bill Page <[EMAIL PROTECTED]> wrote:
>
> > Contrary to some people, I think BOOT was and still
> > is very important in the overall design of Axiom. You
> > can see everywhere examples of how the language in
> > which something is written affects the look and feel
> > of things written in that language. Clearly no one
> > wanted ScratchPad to look and feel like lisp (but
> > perhaps work like lisp, yes).
>
> Is this still true? I have heard a couple variations
> of the BOOT/Lisp story, but I haven't heard there was
> a consensus that the look and feel of Lisp should be
> avoided.
I am sorry Clifford but your question strikes me as very
peculiar. As I said, I thought this was obvious. Let me
illustrate with some examples chosen at random.
In Axiom here is an example of some of the lisp code:
(defun MAKE-HASHTABLE (id1 &optional (id2 nil))
(declare (ignore id2))
(let ((test (case id1
((EQ ID) #'eq)
(CVEC #'equal)
(EQL #'eql)
#+Lucid ((UEQUAL EQUALP) #'EQUALP)
#-Lucid ((UEQUAL EQUAL) #'equal)
(otherwise (error "bad arg to make-hashtable")))))
(make-hash-table :test test)))
----------
Here is some example BOOT code:
genTempCategoryTable() ==
for con in allConstructors() repeat
GETDATABASE(con,'CONSTRUCTORKIND) =
'category => addToCategoryTable con
for id in HKEYS _*ANCESTORS_-HASH_* repeat
item := HGET(_*ANCESTORS_-HASH_*, id)
for (u:=[.,:b]) in item repeat
RPLACD(u,simpCatPredicate simpBool b)
HPUT(_*ANCESTORS_-HASH_*,id,
listSort(function GLESSEQP,item))
---------
And finally here is an example of some SPAD code:
Table(Key: SetCategory, Entry: SetCategory):
Exports == Implementation where
Exports ==> TableAggregate(Key, Entry) with
finiteAggregate
Implementation ==> InnerTable(Key, Entry,
if hashable(Key)$Lisp then HashTable(Key,
Entry, "UEQUAL")
else AssociationList(Key, Entry))
-------
(Exercise for reader: find where in the Axiom source
these code segments are taken from. ;)
The point that I was making is that the target language
for the Axiom library (SPAD) is intended as a higher level
description of the mathematical algorithm, whereas BOOT
looks like most high level programming languages in common
use today (e.g. Python), but in comparative terms lisp
looks at best like a high level assembler language. It
is too close to the machine to be good for expressing
general abstract mathematical ideas.
It seems obvious to me that ScratchPad was intended to
present to the user the highest level language possible
for the expression of mathematics but which could still
be interpreted and compiled by a computer.
> If so, I would be very interested in the rational behind
> this decision. SPAD/Aldor definitely doesn't look like
> lisp, so perhaps I am missing something - how does BOOT
> usefully impact the "feel" of Axiom to the normal programmer
> (who will mostly be working with SPAD/Aldor?)
Of course I cannot speak to the actual rational - I wasn't
there. Tim Daly has described the environment in which this
work as done very clearly.
But you missed my point. BOOT has nothing directly to do
with the SPAD/Aldor programmer. Lisp was used to create BOOT.
It doesn't look much like lisp anymore but in some ways it
still "feels" like lisp. BOOT was used to create the SPAD
language. The structure of SPAD was of course influenced
by the look and feel of the BOOT language.
The BOOT language is relevant to those people who want to
debug, maintain and enhance the Axiom system.
> Below the level of SPAD/Aldor I guess I'm confused as to
> how lisp vs. non-lisp is helpful - are some concrete
> examples available?
The issue is not lisp vs. non-lisp. All of Axiom *is* \1
ultimately written in lisp. Instead the issue is how lisp
is used in various parts of the system. Large parts of Axiom
were built in a layered manner, i.e. as a series of levels.
This is a common and effective design strategy for complex
systems. From my point of view BOOT forms a very important
intermediate level in Axiom because it allows programmers
to write at a more abstract level than just low level lisp.
Some of the opposition to the use of BOOT on the part of
lisp programmers is quite natural since BOOT (by design)
limits some of the types of programming styles that a lisp
programmer might find natural. But I think this may have
been one of the intentions of the overall design of Axiom
since as I said, I think people wanted the Axiom programming
language to look very different than lisp.
Footnote:
1\ Of course Aldor, as the next generation of SPAD, was
actually written in "C" not lisp (that is another story).
But the design of Aldor was inherited from SPAD.
>
> > So it was an inspired idea, I think to first write a
> > language that was "half way in between" so as to speak.
>
> The problem with such a language is that it raises the bar
> even further for new programmers.
No, I don't think so. BOOT is written in lisp and if it
was properly documented, then I think understanding it's
relationship to lisp and how to use it to create SPAD and
the Axiom interpreter would be quite straight forward.
In lisp, it is a very natural design strategy to use lisp
to write a new language or to enhance lisp in other ways
as a step towards creating a final product. So understanding
a design necessarily might include understanding some
intermediate language specifically created for the purpose
of the design. The situation is not so different from say,
having to learn how to use lex and yacc when writing a
Fortran compiler in the C language.
> Lisp has survived a VERY long time, is well defined, and
> had some truly amazing software created using it - I at
> least could use some convincing that BOOT has concrete
> benefits that justify another learning curve.
No, you do not understand. BOOT is written in lisp and was
an integral part of the original Axiom design. Yes, Axiom
could have been designed without BOOT, but then one might
have lost the advantages of the hierarchical design strategy.
As a result it would have been more difficult to create
nearly some complex and high level a language as SPAD.
I might venture to guess that at least in part some of the
differences in Maxima versus Axiom is due to this design
strategy.
> Aldor I can see, since that level of Axiom coding is geared
> very specifically toward mathematics, but below that level
> it's not as clear to me. This could simply be ignorance on
> my part.
Think about building Axiom as a series of layers. The top
level is the Axiom interpreter. Slightly below that would be
the SPAD/Aldor library. Below that BOOT. And below that lisp.
(Actually, Tim Daly has also described some other intermediate
layers in Axiom that are also present.)
>
> > If one were to drop boot, I think one might risk
> > the long term logical integrity of this design.
>
> Are there some design documents somewhere from the original
> project that detail this goal? I confess the impression
> I had of BOOT was that it was the consequence of irreconcilable
> differences among the original developers about coding style,
> but perhaps there was more to it than that.
>
Perhaps I am deluding myself, but I like to think that I am
in a sense, continuing to represent that side of the Axiom
project that maintained this apparently irreconcilable view -
since Tim Daly is still here to represent the opposition. :)
I think that this "tension" was (and still is) an important
part of the reason for Axiom's phenomenal success in the
representation of mathematics by computer. Of course that
might be just empty philosophy and maybe we really cannot
know why one project succeeds and another fails or how to
do it again...
Regards,
Bill Page.
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
