axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Aldor and Lisp


From: C Y
Subject: Re: [Axiom-developer] Aldor and Lisp
Date: Wed, 19 Oct 2005 07:24:32 -0700 (PDT)

--- Martin Rubey <address@hidden> wrote:

> Dear all,
> 
> concerning the freeing of Aldor, Ralf told me a week ago or so that
> there is some hope. It seems that Stephen is looking at the issue, 
> but "it's not settled yet".

Good news!

> > > An alternative that does exist (maybe) is to make incremental
> > > improvements to Axiom's built-in SPAD compiler that would make 
> > > it more compatible with Aldor. 

[snip]

> As you probably know by now, this is my favorite option, too. I would
> like to point out, that we will not be able to use "full" Aldor for 
> Axiom, even if it's free, since the Axiom interpreter doesn't 
> understand dependend types. 

I thought one of the goals was to expand Axiom's abilities as needed to
take advantage of Aldor?

> Generators and exceptions don't seem to 
> be so important to me. In fact, concerning generators, I don't see 
> the advantage over Stream yet.

Um.  Not qualified to have an opinion - need an Aldor guru here.

> And I think that Spad should be improved by using boot or common
> lisp. Not yet another language to learn! Spad/Aldor itself would be
> acceptable to me, but as I detailed before, I think it will be 
> easier to attract Lisp knowledge than anything else. (Thanks Camm,
> by the way, for supportin my post!)

I agree I would hate to abandon Lisp.
 
> > > I still think however that even improving SPAD will not be 
> > > easy.  It will require rather deep knowledge of the largely 
> > > undocumented legacy code that currently implements SPAD in Axiom.
> 
> We will need this knowledge anyway to understand the interpreter, I
> guess.

More than that, I don't think we can regard SPAD being "undocumented
legacy code" as being compatible with the 30 year horizon.  I don't
think we can regard the compiler and supporting code as being exempt
from the literate programming requirements - they are essential to the
system and the choices put into the language design have far reaching
consequences.  Because of this, to me the debate of reusing Aldor vs.
updating SPAD vs. just sticking with SPAD is a bit moot, because
regardless of which way we go we are going to have to dive in and
create a functioning language support for Axiom that is both well
understood and well documented as literate programming code.  That's
the hard part, and the specific code we wind up using is almost a
detail.  Several people have noted that we are faced with a large task
because we don't have people available with the required expertise in
Aldor/SPAD/Lisp/compiler design/what have you.  To me this is the most
compelling argument yet for getting in there, doing the research,
making literate documents out of everything, and documenting the
reasons for design decisions.

> I'm absolutely certain that the reason for this was rather a
> political than a technical one.

I take it you mean in the sense that they figured they wouldn't be able
to get programmer effort devoted to Aldor if it were written in Lisp? 
Or some manager said "why hire expensive lisp programmers when we can
do this in C?"

>  > Is SPAD irreparably deficient in some way?

[snip]

> I do think that the Spad compiler could need improving, but my goal
> is rather to have a good Algebra hierarchy and sufficiently many 
> developers. A dozen is just not enough. And, moreover, we need to 
> attract more genuine mathematicians, i.e., researchers. If this 
> doesn't change within a year or so, Axiom is probably doomed to 
> die.

As somebody said, "it ain't over 'til it's over."  I take it you are
concerned that technical issues like the compiler will distract from
mathematical improvements?  This is a concern but remember one of the
goals of Axiom is to be robust "in the long term," which is difficult
if the supporting superstructure shifts under it too much.  I don't
think mathematical development need wait on these issues, surely - we
are already functional and I doubt enough new work will happen to make
the situation of shifting compilers any more overwhelming than it
already is.  We aren't going to throw out all the work done to date -
on the contrary.  We want to polish it up and preserve it.

> In this vein, getting into contact with Singular is one of the best
> things that could happen to us. 

Agreed.  But unless I'm misunderstanding something I don't think
mathematical developments with the Singular team need wait on compiler
issues?

> A second community, that is *huge* and were several people are 
> interested in contact is R. By coincidence, the sit in Vienna, and
> I'm at the institute of statistics currently. So I
> guess, this is my job. I'll post a message, I think.

Sounds good!  My recollection is that R is a largely numerical tool -
are you thinking it would make a good replacement for the NAG
libraries?  

I agree we need more attention from academic institutions and
researchers, but I'm not sure how to go about it except attempt to
force our way in by sheer merit.  One idea might be to pick several
modern ideas from recent journals, implement them in Axiom, and
demonstrate some non-trivial academic benefit that can be gained once
they are implemented in Axiom.  The problem is the academic community
is used to new systems appearing - it is not clear what would make a
given system into a "winner" that would result in mass adoption.  The
best idea I can come up with is demonstrate non-trivial useful research
on current hot topics as assisted by Axiom.  Mathematica seems to have
made itself secure by being demonstrably useful in a wide variety of
practical engineering and scientific situations - perhaps the same
technique could work for Axiom on the more theoretical side.

Cheers,
CY


        
                
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com




reply via email to

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