[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Axiom-developer] sbcl and Axiom
From: |
Page, Bill |
Subject: |
RE: [Axiom-developer] sbcl and Axiom |
Date: |
Wed, 26 Jul 2006 10:47:46 -0400 |
On Wednesday, July 26, 2006 4:29 AM Juergen Weiss wrote:
>
> The SPAD parser is actually able to translate boot to lisp.
> So you do not need the bootsys image. You can build the
> depsys image immediately (as Bill noted you need a few
> pretranslated files from the interpreter directory).
Now that I have looked more closely at the axiom_cmu build
I am amazed at how much shorter and simpler it is than the
current Axiom build process (of course there are still a
few steps missing).
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.
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.
>
> The quoted function stuff refers to the usage of for example
> map('car, ....) in the sources (lisp and boot). I had to
> change it to map(function car, .. ) in boot and map(#'car .. )
> in lisp. Not a big deal but distributed all over the sources.
> This change should be made for gcl as well.
>
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).
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. 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.
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.
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. :(
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. 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.
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.
Is there nothing we can do to improve this situation?
Regards,
Bill Page.
- Re: [Axiom-developer] sbcl and Axiom, (continued)
- Re: [Axiom-developer] sbcl and Axiom, root, 2006/07/26
- Re: [Axiom-developer] sbcl and Axiom, Gabriel Dos Reis, 2006/07/26
- RE: [Axiom-developer] sbcl and Axiom, Page, Bill, 2006/07/27
- Re: [Axiom-developer] sbcl and Axiom, root, 2006/07/26
- RNG vs. RING was: Re: [Axiom-developer] sbcl and Axiom, Ralf Hemmecke, 2006/07/27
- [Axiom-developer] Re: Rng, Martin Rubey, 2006/07/28
- Re: [Axiom-developer] Re: Rng, Ralf Hemmecke, 2006/07/28
- Re: [Axiom-developer] sbcl and Axiom, Ralf Hemmecke, 2006/07/27
- RE: [Axiom-developer] sbcl and Axiom, Page, Bill, 2006/07/26
- RE: [Axiom-developer] sbcl and Axiom, Weiss, Juergen, 2006/07/26
- RE: [Axiom-developer] sbcl and Axiom,
Page, Bill <=
- RE: [Axiom-developer] sbcl and Axiom, C Y, 2006/07/26
- RE: [Axiom-developer] sbcl and Axiom, Page, Bill, 2006/07/26
- Re: [Axiom-developer] sbcl and Axiom, Gabriel Dos Reis, 2006/07/26
- RE: [Axiom-developer] sbcl and Axiom, C Y, 2006/07/26
- RE: [Axiom-developer] sbcl and Axiom, Page, Bill, 2006/07/26
- Re: [Axiom-developer] sbcl and Axiom, Vanuxem Grégory, 2006/07/25
- RE: [Axiom-developer] sbcl and Axiom, Page, Bill, 2006/07/27