axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] A possiible "navigation" approach for Axiom "cryst


From: Bill Page
Subject: RE: [Axiom-developer] A possiible "navigation" approach for Axiom "crystal"
Date: Tue, 6 Apr 2004 19:05:10 -0400

Camm,

On Tuesday, April 06, 2004 1:40 PM you wrote:
> 
> "Bill Page" <address@hidden> writes:
> ... 
> > If you haven't yet looked at Python, then I very strongly
> > recommend that you do. From the point of view of Axiom, Python
> > looks (almost exactly!) like the Boot sub-language in which
> > most of Axiom is written. I would even go so far as to suggest
> > that it might be possible (even quite easy?) to port most of
> > Axiom to Python. Doing so would have some very important
> > advantages because of the extensive support that Python has
> > for current computing environments.
> > 
> 
> Just a few comments here -- disclaimer -- I've never used 
> python myself. 
> 
> To my understanding python is a great language, but I don't 
> think it would be a good idea to re-implement AXIOM in 
> python.

Well, I didn't go so far as to actually say that it would be
a good idea ... <grin> In that sense I am not really serious.
GCL is a wonderful basis for AXIOM as it stands right now.
And you are making it even better very quickly!

But of course the situation is quite a bit more complicated.

In a sense AXIOM is not really implemented in lisp. It uses
lisp to implement a "higher level" (or maybe better stated:
"syntactically sweeter") language called BOOT. And it uses
BOOT to implement a still higher level language SPAD (and
from Tim's description maybe some other intermediate language
variants). The AXIOM interpreter is also written in BOOT.
The SPAD compiler compiles to lisp (or perhaps BOOT as an
intermediate?) Most of the non-algebraic parts of AXIOM are
written in BOOT, while the algebraic parts are in SPAD. etc.

Then GCL in turn generates C code which is compiled by GCC
etc.

Python is a byte code interpreter. There are some quite
efficient byte code interpreter implementations of lisp such
as CCL. One version of AXIOM was implemented in CCL.

Finally there is this popular introduction to Python

  http://www.norvig.com/python-lisp.html

which starts like this:

Python for Lisp Programmers

This is a brief introduction to Python for Lisp programmers.
(Although it wasn't my intent, Python programmers have told
me this page has helped them learn Lisp.) Basically, Python
can be seen as a dialect of Lisp with "traditional" syntax
(what Lisp people call "infix" or "m-lisp" syntax). One
message on comp.lang.python said "I never understood why LISP
was a good idea until I started playing with python." Python
supports all of Lisp's essential features except macros, and
you don't miss macros all that much because it does have eval,
and operator overloading, and regular expression parsing, so
you can create custom languages that way. 

-----------

> The main advantage of python is that it arguably has 
> a larger pool of knowledgeable users and developers than
> lisp does at this point.  This is offset in my mind at least
> by the observations that 1) the language is still a moving 
> target 2) it is much slower/less efficient than lisp in 
> general, 3) a good deal of its popularity stems from the fact 
> that it has evolved the furthest towards lisp of the various 
> popular scripting languages -- it even has a 'lambda',

I think what you say is true, although some people have
argued that it is not that much less efficient than compiled
C or lisp code. It is strange (and certainly widely discussed)
that lisp is much older (ca. 1960's) and more capable but
Python is new (1995?) yet has a large pool of users. I think
this really tells us something about the nature of programming
since I don't think one can blame the lack of adoption of
lisp on politics or other even less substantive influences.

> 4) we have way too much work to do as it is :-),

A have to agree there!

> 5) while quite portable, I am unaware of any environment to
> which python could carry axiom to which gcl does not already
> carry axiom, 

True.

> 6) lisp has a far longer history of real world use,

True.

> 7) it is unclear who will still be using python when the next
> hot thing comes along or the development of the language ends, 
> whereas lisp appears to endure forever :-).
>

Yes, odd isn't it? But we could say something rather similar
at the hardware level. We are still all using the same basic
design of computer - so called von Neumann architecture - that
was developed nearly 50 years ago. There is something quite
literally universal about it.

Theoretical linguists (e.g. Chomsky) have argued that all human
languages also have some kind of underlying universal grammar.
But no known living language actually uses this grammar although
there are hints of it in the way people - particularly children
actually learn language. Each one has its own variant that somehow
maps to the universal.

I think AXIOM is an excellent environment in which to observe
high level computer programming languages, particularly so
because it attempts to mimic many aspects of the only other
kind of universal language that I know of - mathematics. Almost
nothing we do with computers these days is sufficiently "high
level" to deal with the kind of abstractions that mathematicians
use daily.

I have been reading a paper "Categorical Analysis" by Zbigniew
Oziewicz and Guillermo Coutino

  http://www.arxiv.org/abs/math.CT/0101115

The authors present an abstract graphic language (tangles) for
reasoning about categories. Under the section heading "Why?"
They quote Dieudonne:

"Half the success (in mathematics) depends on a proper choice
of notation"

and then write: "Unfortunate notation might kill fortunate
ideas."

It seems to me that this epitaph also largely applies to lisp
and indeed to AXIOM and other computer algebra languages as
well.

> Just my $0.02.
> 

We all owe you considerable more than that for all your
invaluable work on GCL!

Cheers,
Bill Page.





reply via email to

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