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.


Allegro CL is ANSI, and I had a build routine for Maxima 5.2. It was
probably not quite as successful as GCL, and it certainly did not do
the fancy front end.  I think that it does not take much effort to
bring it up to latest Maxima. Yet there may be pieces that fail to work
with mk:defsystem.


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


And for ACL, there is another file, I think.  Probably I sent one in
a while ago.


> 
>     James> 2) Greatly reduce the number of conditionals (i.e., #+Multics) in the
>     James> code. Use the "port" package from CLOCC whenever possible. Remove
>     James> support for PDP10, Multics, etc.
> 
>     James> 3) Reformat the code to consistent case and indentation conventions,
>     James> without changing any of the logic. Perform the case and indentation
>     James> stages in separate steps committed to CVS.
> 
> I disagree with 2) and 3).  It's way to easy when doing these things
> to say "Hey, this is ugly.  Let me just tweak it like so."  And
> suddenly some weird case breaks and no one knows where now because
> EVERY single line has been touched.  It ain't broke so don't fix it.
> However, I have no problems if something is broken and you fix it and
> reindent and change case too.
> 
> Although I find the code written in a unique style, I can read and
> understand some of it.  Internals and stuff are beyond me right now
> though. 
> 
> Ray
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
> 

My suggestion is that if something is broken
that either the minimal patch be found,

or if someone is ambitious,

the interfaces to major routines be thoroughly documented and
a whole "file sized" replacement be considered.  The major routines
are those used from outside that file, and typically will be
only a few in each file.

Just a thought...
You may find that the best documentation for some features is
exactly the stuff you want to remove.  That is, the multics or pdp10
code which has the same functionality but in a different lisp may
actually explain what the CL is trying to do!