[Top][All Lists]

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

RE: [Axiom-developer] axiom common lisp

From: C Y
Subject: RE: [Axiom-developer] axiom common lisp
Date: Thu, 17 Nov 2005 13:06:19 -0800 (PST)

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

> On November 17, 2005 3:06 PM C Y wrote:
> >
> > To a point that may be true, but making old code run by
> > implementing layers that mimic the behavior of older lisps
> > is not something I would argue is a good thing.
> But Axiom has had just such a compatibility layer for a long
> time and it has served Axiom well, otherwise we wouldn't be
> using Axiom today.

Right, but Axiom is now open source - the clarity and transparency of
the code now becomes much more important than for a commercial project.
 Being just functional is insufficient for open source (IMHO anyway)
but in a commercial program the source code is never seen, so as long
as it is functional it is no problem.

> > It makes the code much harder to understand, because to work
> > with any given part of the code you have to first understand
> > what version of lisp that part of the code was written for
> > (and consequently what behavioral assumptions were made) and
> > then try and work with it.
> I think you may be arguing based on a rather unclear idea of
> just how flexible a language lisp is - any version of lisp
> and especially ANSI common lisp, which for the most part is a
> superset of other lisps, rather than a refinement. (Notice
> that I said: for the most part.) To understand any lisp code
> (pick almost anything off the web) and you will find that to
> understand how something works you first have to understand
> the author's design.

True.  I make no claim to being an expert lisp programmer, and for this
reason I may be overestimating the issues involved.  However, I know I
would be very wary of behavioral inconsistencies between changes in the
standards and how they would impact the coding requirements.

> > For younger coders especially, that can be a high hurdle -
> > they have no knowledge of obsolete standards.
> I think that is wrong. Do you really think that learning to
> program in Fortran is made seriously more difficult because
> the year 2000 Fortran standard is radically different than
> the year 1964 Fortran standard? Standards are important for
> very different reasons, but learning to program is not one
> of them.

I know if I had learned to program in 2000 Fortran I would be very wary
of assumptions and behaviors learned when editing 1964 Fortran, and
possibly subtle bugs I could introduce by using the wrong assumptions
when working on the code.  But I might be overestimating the problems -
I have no experience to base a judgement on.

> I think you have it backwards. Layers, when done properly, do
> not increase the complexity of the code, they decrease it. I 
> haven't looked much as Maxima, but I suspect that some of 
> the "complexity" that you talk about in Maxima is due the use 
> of a design that does not take advantage of this design idea.

Probably true.  Certainly, it was not modular enough - almost
everything is jammed into one huge lisp package, for example.  I am
unsure of whether introducing language variations would have
contributed anything.

> It has been claimed here that the Maxima source is now fully
> compliant with the Common Lisp standard. Is there any 
> information available from the Maxima developers about what 
> changes were necessary to attain this goal?

I think this was a very gradual process.  The cvs history might offer
some insight, but I myself don't know too much about the issues

I should pose this question of defining languages within lisp on
comp.lang.lisp and see what the real gurus think.  Or maybe it has been
asked already - I'll see what I can find.


Yahoo! Mail - PC Magazine Editors' Choice 2005

reply via email to

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