RE: [Axiom-developer] axiom common lisp

[Bill Page]

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

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

> From this standpoint, making the changes to get to ANSI lisp
> now would just result in duplicate effort in the long run, 
> and would be of questionable benefit since it makes far more
> sense to test Axiom on multiple lisp implementations after it
> has been rewritten in a cleaner fashion.

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

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

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.

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

> 
> Tim, if patches were made available that would allow Axiom to
> transition to ANSI GCL would there be any chance they could
> be merged in with the latest release branch?  Or do we want
> to avoid dealing with the problems that will surely crop up
> moving between Lisp implementations until the proper rewrite
> is done?  
> 

I don't see why Tim doesn't stop grinding old axes like boot
vs. lisp and just merge in Jergen Weiss' changes now. The
sooner we get to a point where Axiom can be built under a
common lisp compliant system the better. Once we are there,
we can worry about cleaning things up (whatever that might
mean to those doing the work) in a gradual and incremental
manner.

Regards,
Bill Page.