RE: [Axiom-developer] sbcl and Axiom

[C Y]

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

> As Juergen implies, building depsys from bootstrap Clisp
> files is really no different than the way that Boot itself
> is bootstrapped. Since SPAD can process boot files it seems
> bootsys is completely unnecessary. This makes it even more
> clear that spending time working to eliminate code written
> in boot is a gross waste of time unless we were also planning
> to eliminate the SPAD compiler itself and this certainly
> wont happen until/unless we have an open source version
> of Aldor.

Of course, until the interp files become lisp in the standard tree we
will still need the bootdir.

Now that I understand what's going on with the bootsys -> depsys image
process, sys-pkg.lisp presents much less of a problem.  It seems I just
spent two days getting bootstrapping the boot code (sort of) working
under sbcl, when the axiom_cmu approach indicated that this wasn't
necessary except in the case where no clisp files are available for the
interp dir (the situation Tim was originally faced with, but not a
current limitation).  Oh well.  I'll probably keep poking at this just
for the fun/learning experience - I'm curious how much further I can go
without major changes to the source code :-).

> Just like the algebra code written in SPAD and Aldor, boot
> code is translated to Lisp. Reverting that code back to
> Lisp is a retrogressive step that does not make any sense.
> 
> In the quest to simplify the build process and make it more
> easily understandable and therefore maintainable, it does
> make sense I think to eliminate the first two steps in the
> process that Tim Daly outlined in a previous email. Already
> the Debian build eliminates the first step. Using the method
> implemented by Juergen Weiss for axiom_cmu it is also possible
> to also eliminate the 2nd step.

In essence, at least enough of the interp code has to be in lisp to get
a functional compiler for boot/SPAD/etc. The "bootstrapping" code is
basically in interp in that case.

> Time spent converting the existing Lisp code and the generated
> Lisp code to conform to the common lisp standard is obviously
> time well spent, as are efforts to port Axiom to other lisp
> platforms besides GCL. But seems really unfortunate to me that
> we are still in the situation where we have only one active
> Axiom developer working in Lisp (Tim Daly).

Agreed.  But moving the generated Lisp code to ANSI is only of use if
one never plans to generate the code again.  It seems this is indeed
the plan for the boot level code.  However, the SPAD compiler will have
to be adjusted to output ANSI lisp, unless we get a Free aldor first. 
If there is overlap between the SPAD abilities and the BOOT abilities,
perhaps a "tweaked-to-ANSI" boot compiler would be of some user after
all for patching the SPAD code.

> Although I do believe that Lisp is a beautiful programming
> language, from an objective point of view it seems clear to me
> that it is Lisp itself that is the problem. In spite of having
> advertised repeatedly over the last two years in the Lisp
> community for help with Axiom, no one knowledgeable and
> experienced in Lisp programmers have stepped forward.

I can tell you that most of the open source lisp coders out there are
not likely to want to go wading through the old lisp code in Axiom -
they won't have the background to understand it properly, and cleaning
up old code to ANSI isn't the most thrilling programming.

> On the other hand we have had numerous and ongoing discussions about
> Aldor, SPAD, and other high level languages like Haskell and
> ML. It might be a sad thing but these days Lisp is just not
> sexy enough. And it does not attract a significant portion
> of the available open source programming resources. It seems
> there is nothing that we can do in promoting Axiom as open
> source that is likely to change this.

I think making Axiom behavior more like a "normal" lisp program - ANSI,
asdf, etc - will go a ways to changing that.

> Languages like Boot, SPAD, and Aldor on the other hand are all
> precursors to languages that are currently undergoing rapid
> development, e.g. Python, Ruby, Haskell, Ocaml and several
> others. They seem to have significant appeal to a majority
> of open source developers and are being rapidly adopted for
> many large and significant projects. In my opinion we should
> be actively promoting this aspect of the Axiom project and
> *not* attempting to eliminate it. As far as I can see, this is
> the only way that we have any chance of increasing the number
> of active Axiom developers.

The interp type of programming isn't going to appeal to many people no
matter what language it's written in, IMHO.  There's nothing really
"new" there, just framework building.  It's a bit like programming a
word processor - very useful, but not very exciting to a lot of
programmers (particularly of the more academic sort - you don't often
publish papers about revitalizing old interperter code).  It's utility
is what it makes possible, and there is a certain satisfaction in a
well designed framework, but I doubt those will be big draws.  

I am hoping the interperter will be one of those sections of the code
that will eventually be "finished."  Maybe not the compiler part, but
the more mundane parts at least.

> I know Tim has proposed Axiom as a long term project with a
> (rolling?) 30 year horizon, but I have worked fairly aggressively
> on the Axiom project now for nearly 3 years and I am frankly
> quite disappointed at how little progress we have made. :(

I think it's equal parts non-Standard Lisp, non-Free Aldor, and Really
Tough Subjects ;-).  People won't commit to Aldor until it is free
software, and the lisp guys aren't likely to enjoy weeks of fixing old
code and trying to figure out what it is doing.

> Even new and innovative projects like Sage:
> 
> http://modular.math.washington.edu/sage/
> 
>   (Thanks for the reference Frédéric Lehobey.)
> 
> have choosen to implement an interface to Maxima first before
> seriously considering Axiom.

Maxima has a couple years head start on Axiom in the mindshare
department, and its name is more widely known.  Maxima had the
advantage of stepping into a virtual vacuum in terms of heavy-duty
open-source CAS - there were a few, but none very strong in the
symbolic side.  Maxima has also gone through a lot of trouble to make
itself easier to interface with - check the archives for some of the
history on that, particularly the prompts work.  Then too, Maxima
compiles and builds on ANSI lisp platforms.

More fundamentally, I think Maxima appeals to the Mathematica types by
not worrying about strong typing et. al., but just going for the
answer.  It's "easier" in some sense to deal with.  I know for myself
my first impression of Axiom was rather overwhelming.  I think now that
Axiom has more long term potential and its ideas are more likely to
scale, which makes it worth the effort, but folks not looking for such
broad ambitions and potential will be able to get started with Maxima
more quickly.

> And the situation is similar with
> TeXmacs - the other major open source project that integrates
> a large number of open source computer algebra tools. The Maxima
> interface for TeXmacs is greatly superior to the current Axiom
> interface.

IIRC there is really one one major developer for the CAS<->TeXmacs
interfaces (aside from the main developer of TeXmacs).  

I haven't tried the TeXmacs-Axiom link in a while - what are its
limitations?  I seem to remember some comments on the problems with
interfacing with Axiom sometime in the past - not sure where though.

> And on the mathematics front I seems we aren't doing much better.
> In spite of a lot of apparent interest, we still have not
> collected nor have there been initiated more than just a few
> (two or three) projects involving Axiom.

Since we are targeting our major language at the mathematics level to
be Aldor, and Aldor is not yet free, this doesn't surprise me much.

> Is there nothing we can do to improve this situation?

I think we need to await developments on the Aldor front.  A robust,
unquestionably free framework will attract more people, I think, than
the current situation.  Even if we are forced to stick with SPAD and
try to fix it, that at least is a concrete direction forward - an
answer one way or the other will be a big help.

Clear directions and tasks I think are always a help in keeping a
project like this moving - the circumstances currently prevent this
from being the case, for the most part.

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com