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. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
