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