axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] axiom common lisp


From: Bill Page
Subject: RE: [Axiom-developer] axiom common lisp
Date: Thu, 17 Nov 2005 15:48:24 -0500

On November 17, 2005 3:06 PM C Y wrote:
> 
> --- Bill Page wrote:
> 
> > 
> > Looking at the Axiom lisp code it is obvious that it contains
> > multiple layers and multiple styles, but I think it is not
> > correct to class this as "bizarre". Allowing such a mix of
> > layers and styles is one of the things that lisp is good at.
> > It only looks complex because it is not well documented (or
> > not documented at all).
> 
> 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.

> 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.

> 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 can see layers being used to more closely match ideas
> (e.g. SPAD vs. Lisp) but defining layers to match old code
> behavior rather than making that code work with a now long
> established, agreed upon standard (Common Lisp) is one of
> the better ways to guarantee no one will ever want to touch
> the old code later on.

As I said, Axiom already has a sort of lisp-variant compatibility
layer implemented as a set of macros that is built-in to it's
design. Understand this layer is not particularly difficult.

> 
> Well, maybe it isn't "fragile" - say rather there are too many
> layers of complexity that do not directly benefit the goals of
> Axiom.  Or, from experience with Maxima, too much complexity
> in the code makes it impossible to say with certainty that any
> particular change will impact only what it is intended to impact.

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.

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?


Regards,
Bill Page.






reply via email to

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