A few modest proposals for maxima maintinability

Raymond Toy wrote:
> 
> >>>>> "James" == James Amundson <amundson@fnal.gov> writes:
> 
>     James> There has been quite a bit of discussion here about future directions
>     James> for Maxima. The maintainability of the existing code should be the very
>     James> first concern. I have a set of modest proposals to enhance the
>     James> maintainability of the code base:
> 
>     James> 0) I would like to see the code base focus on ANSI CL first, existing
>     James> Lisp implementations second.
> 
> Isn't already pretty close?  CMUCL and Clisp are pretty close to ansi
> and maxima works with them.  There are some issues on debugging though
> because the code uses evalhook which is CLtL1.  CMUCL doesn't have
> this.
> 
>     James> 1) Port the build system to mk:defsystem from the Common Lisp Open Code
>     James> Collection (CLOCC, see <http://clocc.sourceforge.net>;.) Right now the
>     James> build process for GCL is totally different for than that for CLISP and
>     James> CMUCL. I don't think anyone can build Maxima under anything but GCL
>     James> right now without looking under the covers.
> 
> But for CMUCL all you have to do is read the comments at the beginning
> of compile-cmulisp.lisp and you know how to build it.  The same
> approach works for Clisp.

You are correctly representing the Maxima status quo. I am proposing a
modest change to the priorities for the future of Maxima. The situation
to date is this: Maxima works well with GCL. It mostly works with CLisp
and CMUCL if you do things like read the comments in some lisp files and
ignore functions which rely on non-ANSI code. I would like to change
priorities so that working well with ANSI code comes first, not last. I
would also like to change the build system so that switching between
lisp implementations is more transparent than it is now. I think Maxima
will be better off in the future if it is not tied as closely to the
highly idiosyncratic GCL as it is right now.

Best,
Jim