RE: [Axiom-developer] axiom common lisp

[C Y]

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

> On November 17, 2005 9:17 AM C Y wrote:
> > 
> > I think the point should be made that Tim (the "root" Tim) is
> > taking a more measured approach - rather than just making the
> > code work on ANSI lisp implementations, he is going in and
> > addressing/eliminating the multitude of bizarre layers that
> > have accumulated over the decades.  (I think - feel free to
> > correct me Tim :-).
> 
> 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.  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.  For younger coders especially, that can be a high
hurdle - they have no knowledge of obsolete standards.  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. 
 
> > This may not "get us to ANSI Lisp" as fast as making the 
> > smaller changes would, but the result will be far more 
> > understandable,far easier to work with, and far less fragile
> > than the current state of affairs.
> 
> I don't think that there is any proof of that. I don't think
> that the Axiom code is "fragile". It is just difficult to
> maintain because the documentation is so poor (mostly absent).

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.  Maintaining compatibility with
older styles of coding doesn't help anything in the long run. All it
does is avoid the task of revisiting older code and redoing it to match
modern standards.  It could be argued that such standards are
themselves a moving target but I think at this point the ANSI spec is
pretty well established.

> "Clearer fashion" is another issue of style and style is
> subjective. I have no doubt that the current approach will
> make it easy for Tim to maintain - since he is the one actually
> do the re-writing - but except of the new documentation I
> do not see a net gain.

Well, let's wait for the results before we decide that.  It's early
days yet.  But by "clearer fashion" I ment "without having to cope with
code written to outdated standards and not easily understood (or worse,
easy to misunderstand) by common lisp programmers."

> > Problems brought to light in the current codebase stand a
> > fair chance of being eliminated by the lisp cleanup/rewrite.
> 
> I also doubt this. Because Axiom currently works and has been
> in fact a commercial product for a number of years, I expect
> that most (if not all) the problems in the basic Axiom code are
> of a systemic nature - design oversights or unresolved issues.
> The kind of thing that one sees while converting subroutines
> a few at a time are not of this kind. And re-writing is just as
> apt to introduce new problems as it is to correct old ones.

If we get a result of break even on bugs removed vs. bugs introduced,
and get code which is more readable and understandable in the eyes of
common lisp programmers, I think that's a definite net gain.  But
again, I'll wait for the results to speak for themselves.
 
> Overall I am still very strongly against this approach -
> especially when you mix all this up with the misguided idea
> of removing major parts of Axiom's current architecture like
> boot. Add this to the fact that there is only one person doing
> all this and I think the net result is to set Axiom back a few
> years when we should be concentrating instead on mathematical
> functionality that could potentially attract new users now.

Well, there's nothing to stop the rest of us from working on the
mathematical functionality - that will survive and be useful
regardless.  It would seem to me that the question of the availability
of Aldor would have a more direct bearing on that issue, and I haven't
heard any update on its status for quite a while.

I haven't let the architectural discussions worry me too much, although
granted I'm still slugging it out with Buckingham at the moment so SPAD
code isn't yet an issue ;-).  

> > That said, if the change really is a fairly simple one and
> > there is sufficient interest to get it in place I would vote
> > for it being put in place in order to allow us to transition
> > over to GCL's ANSI environment.  This would be more for GCL's
> > benefit than ours - certainly an ANSI Axiom, even (or perhaps
> > especially) with ANSI being simply the support layer for
> > layers of emulation, would be an excellent stress test of
> > GCL!
> 
> The use of the word "emulation" is not very accurate. As I
> pointed out above, programming in layers is a commonly used
> lisp programming style.

Right, but I only like that idea when the new language/layer is
designed in for some major, non-trivial advantage, not to support older
code - older code should be modernized to reduce the burden on future
coders.  I think the mark of the proper use of a language within a
language is it makes it easier for a programmer with training only in
the "core" language to understand ALL the code - "embedded" language
and known language alike.  

Just MHO, of course - I'm certainly no expert in such matters.

Cheers,
CY


                
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com