RE: [Axiom-developer] Aldor and Lisp

[C Y]

--- Bill Page <address@hidden> wrote:

> > 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.

Sorry, I didn't mean to offend - clearly I'm missing something
fundamental.

> As I said, I thought this was obvious. 

We all got nervous in Calculus class when a professor said something
was obvious ;-).

[snip]

> 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.

Oh, OK.  I see what you're saying.

> 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.

So the way things are organized is SPAD built on BOOT built on Lisp? 
And the core reason for this is that BOOT makes it much easier to build
SPAD than building it in straight Lisp would be?

[snip]

> 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.

OK.  I guess I didn't appreciate how SPAD might be influenced by BOOT.

> 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.

Ah, this is the key point I was missing.  I had the view (I guess
because of my Maxima experience) that the logical way to proceed was
use lisp for everything up to the point where the primary goal becomes
the expression of mathematical knowledge.  Separating it into a series
of layers, each with its matching language, wasn't obvious to me. ;-)

> 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.

This being the case, we should be very clear in the literate
documentation on the purpose for each language, the reasons behind it,
and the advantages to using it (if we provide people with the full
rational, they'll probably be more willing to learn it.)  For myself, I
confess I thought the presence of BOOT was an unnecessary and
unbenficial complication, but that's an uninformed opinion and should
be revisited.

> 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.

So BOOT was made different from Lisp to allow SPAD to be different? 
And the major objection to lisp is that it is too low level?  (Sorry if
those are more dumb questions, I'm just trying to get a sense of the
modes of thinking involved.)

> 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 if at some point Aldor becomes free and we can switch to it, what
are the implications for Lisp and BOOT in Axiom?
 
> > 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.

OK.  In that case proper documentation becomes of paramount importance,
and I would say one of our highest priority tasks (if BOOT survives the
Aldor conversion) should be to get our languages documented so we can
have a reasonable expectation of people being able to learn and program
in them quickly.
 
> 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.

Ah!  OK, that makes sense.

> > 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.

So Lisp -> BOOT -> SPAD is kind of a "bootstrapping" process wherein
each level enables a more abstract or "high level" style of programming
than the previous stage?

> I might venture to guess that at least in part some of the
> differences in Maxima versus Axiom is due to this design
> strategy.

Well, it's hard to argue with success.  The more I see of Axiom the
more impressed I am.

> > 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.)

I guess I'm used to the line of thought that goes "the fewer
programming languages in a project, the better" but that might just be
the consequence of not thinking about the magnitude of the work
involved in the Axiom effort - it could very well be that the effort
put in to learn to work in each layer of abstraction pays off in
increased productivity.

> > > 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. :)

Heh :-).  Fair enough.

> 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...

I think the effect of that tension is to keep people continually
arguing about and defending their design decisions, which is likely to
result in more robust decisions in the end.  I didn't mean to come off
as overly agressive, but I see reading my original email I might have
done so.  Sorry about that - I'm well aware I'm the introductory
student in this project.  Normally a concern in an open source project
is handling things in such a way that we attract developers, but this
is not an ordinary open source project and so I should worry less about
any barriors to entry posed by multiple languages and more about how
they benefit the quality and power of the result.

Cheers,
CY


                
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com