[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Value stack overflow bug

From: root
Subject: Re: [Axiom-developer] Value stack overflow bug
Date: Sun, 8 Jun 2003 21:18:09 -0400

> Could you (briefly) describe how this process would be
> different if you could presume that there was already a
> running Axiom system available? Say, for example, that
> there was a new version of (some part of) Axiom available
> in source code format from CVS plus a running C compiler,
> GCL already compiled and running *and* an older version of
> Axiom running on the system. What would be the most
> convenient and/or most efficient steps to take to compile
> and install the new version of the Axiom code?

The normal installation process for users who have Axiom will
amount to downloading the CVS changes and typing make. Axiom
caches everything possible and even optimizes the code based
on the cached information during the 'update' builds. At some
future point the CVS will include a complete, built copy of
Axiom. The agreement with NAG precludes distribution of their

> > ... 
> > If we were to pursue the aldor route I'd consider scrapping 
> > the axiom interpreter and going to a compile-time only 
> > environment.  This has been discussed several times and
> > it is very, very hard.  Manuel Bronstein has done some work
> > on this path before.  I don't know of anyone that would fund
> > such an effort and I don't believe we would get the research-
> > level expertise for free.
> Perhaps a joint effort with the Aldor people? It is truly
> amazing what one can get for free these days ...

It isn't the aldor expertise that is needed but a comprehensive
understanding of the algebra code. The past code is undocumented
(the future code, nopefully, will correct this). Axiom grew up
as a research tool and represented the bleeding edge of computational
math in various areas. I can read the aldor code but it is hard to
infer WHY some algorithms work. (This is true even in the interpreter.
There are 7 parsers. One is a "zipper" parser done by Bill Burge who
wrote a book on parsing. However, the zipper parser is post-book and
is undocumented both in code and in theory.) In order to understand
the challenge pick up a copy of a computer algebra algorithms book
and consider what it would take to either write the code from those
descriptions or write the descriptions given the axiom code. I hope
to see the "book" level of documentation for Axiom. As part of that
effort it would make sense to rewrite the Axiom code in Aldor.

> > 
> > But if I were to even entertain such a huge job (which, 
> > believe me, I'm not) I'd go the other way and grind it
> > all into common lisp syntax. The ability of a program to
> > read another program as data gives a "second order" power
> > that is hard in Axiom.
> > 
> You mean that this is not possible in Axiom, i.e. programs
> as data? This is not such a foreign idea in high level
> languages any more. For example it is fundamental to
> Python and other languages of that genre. You can even find
> it in Maple's programming language.

Yes, it's possible. It's possible in any language. But the unification
of program source code syntax and program data structure syntax
(lists) is a feature of no other language I'm aware of. How often do
you read a program (as data) in Python, operate on it, spit it out as
Python, and execute the result?

> I have nothing against lisp as such. But lisp has been
> around a long time and for a lot of different reasons
> it has yet to reach it's full potential. I think there
> are good reasons why people are still searching for better
> higher level languages. Axiom (and Aldor) seem to be moving
> in the right direction to me. To return to "just lisp"
> seems like a backward step, no?


Believe me, nobody I've talked to agrees with me on this so you're in
the majority. But I've worked on a Symbolics machine and I've seen the
future, so to speak. (Imagine a world where you can hit an error, edit
the source, find the failing line of source code, change it, recompile
it, load it, and CONTINUE FROM THE POINT OF FAILURE, all in less than
5 seconds. I used to work that way and it was "just lisp").

Block structured languages need, at minimum, special code
walkers/manipulation tools in order to manipulate the sources.  (Think
of all of the Axiom parsers).  Which is hardly the issue. The real
issue is that languages determine what you can think.  The early
concept of computer algebra comes about with the realization that you
can symbolically differentiate program text.  The current generation
manipulates program text for program proofs.  Lisp minimizes the
distance between the thought and the code.

All of Axiom, including the algebra, compiles to lisp. It is currently
possible to write code in lisp if you understand the magic.

Axiom's language is very close to the algebra which is a huge win.
If you understand the domain you can read the Axiom code directly.
That's the huge benefit of Axiom's language. So it's unlikely to change
any time soon.

Not to worry, this is just a thought experiment anyway.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]