RE: [Axiom-developer] Aldor and Lisp

[Bill Page]

On October 23, 2005 2:51 PM C Y wrote:

> 
> --- Bill Page <address@hidden> wrote: 
> > 
> > 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 ;-).
>

No offence. In fact my comment was an admission on my part
that perhaps what I wrote wasn't obvious except to me. I
think you are right to raise your antennae when someone
says something is "obvious". Sometimes this means either
that they are too lazy to explain properly or that they do
not in fact understand it themselves.

Anyway, I think your questions are good ones and serve as
motivation to write something that would otherwise not
be proper expressed.
 
> 
> 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?

Of course as Tim Daly would likely point out, that is a matter
of opinion conditioned by personal style and degree of
familiarity with programming in Lisp. But it is clear that
many (most?) of the original Axiom developers seem to have
held such a view.

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

We all seem to agree that documentation is key to Axiom's
future. The question is: how can we make sure that this
documentation gets written? And after it is written, that it
is accessible when someone needs it? I have been devoting some
effort to building tools to make this easier, such as the new
support for pamphlet files in the Axiom wiki

  http://wiki.axiom-developer.org/axiom--test--1

So now you can view the literate documentation for each module
of Axiom source online and correcting or expanding the
documentation is as easy as clicking 'edit' and then adding
or changing whatever you want.

But I am worried that just making it easy will not in itself
make it easier to write useful documentation because in order
to write documentation, you first have to understand what you
are writing about. And without existing documentation *that* is
the really hard part.

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

Maxim1: "there is no such thing as an easy job"
Maxim2: "there is not such thing as a dumb question"

Yes, I think you understand my point. But it is not quite
correct to call lisp "too low level". For many purposes lisp
can be considered to be a very high level language. But the
concept of level here is relative to the purpose. So, for the
purpose of expressing abstract mathematics, yes lisp was too
low level.

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

Ah, another very good question!

Even with Aldor to replace SPAD, lisp and BOOT are still very
important for the interpreter part of Axiom. The interpreter
provides the user interface and must translate user instructions
into operations from the Axiom library.

It is possible to go further and to imagine writing the Axiom
interpreter itself in Aldor. One can guess that this is one of
the reasons that Aldor was specifically designed also to work
as a stand-alone compiler and not just as the Axiom library
compiler like SPAD. I do not know how much work, if any, has
ever been done along these lines. Unlike changing Aldor for
SPAD as the library compiler, changing the interpreter to Aldor
would not be just an incremental change. The interpreter would
have to be completely re-written from ground up.

Personally I am not sure whether re-writing the interpreter in
Aldor would be such a good idea. Certainly one would gain the
advantage of easily working at the same level as the code in
which the mathematical library is written. But outside of it's
application as a replacement for SPAD, Aldor is still largely
an experimental language. I think it's advantages and disadvantages
relatively to lisp and BOOT or other high level object-oriented
languages like Java, Python, Haskell and Ocaml are largely
unknown. In a sense, this is where research in the Axiom project
left-off when the money ran out... But it is one of the parts
of Axiom that intrigues me most.

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

I don't think it is possible to say that too often unless
saying it happens to get in the way of actually doing it ...
:)

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

Hence the name "BOOT".

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

I would say that "productivity" is not so much the issue as
"creativity". Working at a higher level of abstraction allows
you to concentrate on different aspects of a problem. And of
course this mirrors how a lot of mathematics is also done. So
this approach fits the application quite well.

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

Maybe that is a good thing, maybe it is a bad thing. I think
we have to try to make sure that it does not lead to a stalemate
and end up reducing everyone's motivation to make progress
towards improving Axiom as a whole. I think one thing that we can
use it for is to use it as motivation to continue writing about
and hopefully, documenting more of Axiom.

> I didn't mean to come off as overly aggressive, 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.

Not at all. This might sound "soapy" but I do think that when
you stop being a student is when you stop learning anything new.
So I hope we are all students here.

> 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 barriers to entry posed by multiple languages and more about
> how they benefit the quality and power of the result.
> 

Yes, the "spin" you put on it is important. I think you are
right to be concerned about how to attract developers to the
Axiom project. One thing I am sure Axiom can offer open source
developers is the challenge of working on a leading edge
research project. And I think this is made even more enjoyable
with the knowledge that this line of research already dates
back more than 30 years.

Regards,
Bill Page.