Stavros Macrakis wrote:
> However, most Maxima internals don't include long formulas.
Are there parts that should, but dont currently?
>
> The disadvantages of the Maxima language are many:
>
> -- it is simply not a very well-designed or complete
> programming language;
What parts are missing. In particular, I can think of
multiple values, and in the commercial macsyma,
array handling is not complete.
> -- since it doesn't support lexical scope, variable name
> conflicts with user variables could cause complications;
How big a job is it to fix this?
> -- there are few editing and debugging tools available for it;
Other than emacs, and Dr. Schelters Macsyma source level debugger.
> -- it doesn't benefit from libraries of Lisp functions; though
> it is possible to call Lisp functions using ?function notation,
> since its semantics involve the simplifier, you can't (for
> example) use lists that don't start with (mlist);
Most lisp's have a foreign function notation, perhaps
a function to call lisp functions might be in order.
> -- its existing library of functions is specifically tailored to
> user programming;
What is missing here?
> That is the language. Then there is the implementation. Since it has
> not been used as a production language implementation, it has bugs which
> have never been fixed, including inconsistencies between the interpreted
> and compiled versions (certain flags are ignored, for example). In some
> cases, compiled code is comparable to hand-coded Lisp, in other cases it
> is somewhat inefficient.
It has taken many years for compilers to produce as good assembler as a
person.
However, in many cases it just doesn't matter, the code is fast enough.
> There is another issue which is orthogonal to Lisp vs. Maxima languages,
> namely the style of programming, procedural vs. pattern-driven.
> Currently, Maxima uses pattern-matching in very few places internally --
> the SIN integration package is the only one I can think of off the top
> of my head. You could certainly imagine large parts of the simplifier
> and other modules being written in terms of pattern match and replace.
>
> Maxima does of course have pattern matching facilities. Frankly, I have
> not used them much, so I leave it to Rich Fateman (who if I remember
> correctly wrote them) to comment on their usability, semantics, and
> efficiency. Certainly in principle a pattern-matching implementation
> could be *both* cleaner *and* more efficient than hand-written code.
I think that these issues are ones that should be considered when adding
new functions to maxima, or fixing old code.
>
> So would any of these changes make Maxima more maintainable? Probably
> yes: a pattern-driven, infix-notation system is probably easier to work
> on for many people. Not that it is trivial, of course: interactions
> among patterns can be very tricky; but still it could well be better.
> But how about the intermediate period?
>
> Oh, and by the way, who is going to bell the cat? i.e. who is actually
> going to do the work? And will it have been worth it in the end?
Now that I have moved, I can start working on Maxima again.
> -s