RE: [Axiom-developer] lisp dead code

[C Y]

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

> The concept of grouping code and documentation into "book-sized"
> volumes does not make any sense.

This is why I like the idea of the "conference proceeding" style of
volume building - collect many papers (pamphlets) that pertain to a
particular subject into one volume, but each paper is its own
self-contained sub-unit.

The paper/pamphlet authors don't need to worry about the volumes in
that case, except possibly when it comes to compatibility of LaTeX
packages.

> A monolithic linear presentation of the code does not aid an
> overall understanding of the system. On the contrary it makes
> several things harder to manage and moves the system further
> away from the tools that have been developed specifically to
> deal with large complicated projects. I am all in favour of
> adding more documentation to Axiom and doing it in a literate
> style, but I am quite sure that this is not the way to do it.

I expect there are as many visions for how to handle this as there are
developers for Axiom.  Some time it might be interesting to have
everyone write out a "global design vision for Axiom" and see how they
all differ.

> I am very encouraged however by the work of both Waldek and
> Gaby to improve the build process and to improve the long term
> maintainability of the Axiom code in it's current form without
> the kind re-writing and restructuring in which Tim has been
> indulging.

My take on this is that we need re-writing and restructuring, but until
we have a better handle on what the system is doing now such efforts
are premature.

My take on Axiom in its current form is we have no fundamental reason
to trust its correctness, and it is more important to work towards a
foundation that we can trust first, and THEN re-implement the existing
logic on top of the solid foundation.  Hopefully it would be a fairly
painless migration at the Algebra level, but without a rigorous
definition of SPAD/Aldor I don't see how we can make any strong
correctness claims.

> And I must repeat again that I am even happier that
> they have a strong interest in Boot and have already taken some
> steps in the direction that seemed to be the intention of the
> original developers - integrating the new boot compiler (shoe).

I too am glad to see this, primarily because it looks like the shortest
route to an Axiom that works well on multiple (and more modern)
targets.  I have no particular attachment to Boot or Shoe but
translation of their implementation logic into Lisp in a "good" way is
not simple.  In the meantime Boot/Shoe being runnable elsewhere is a
good thing.

> I would like to see the retrogressive code changes from Boot
> to Lisp that Tim introduced in bookvol5 reversed. With the
> prospect that Boot can now be fully documented and properly
> maintained, if there is any re-writing to be done, then I think
> it is in the opposite direction - from Lisp to Boot.

Not sure I agree here, but it might be more because I'm still at the
starting gate as far as awareness of the guts of Axiom is concerned. 
Also I'm an Admitted Lisp Fan so that's a likely source of bias.

Fortunately, many of the improvements people are making are not
mutually exclusive.  I have my own opinions about how I would like to
see Axiom evolve, but as they say everyone has opinions and mine don't
count for much until I show code to back them.

Those who do have code, regardless of direction, I wish to say thank
you for helping to make Axiom what it is today and what it may become.

Cheers,
CY


       
____________________________________________________________________________________Looking
 for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/