Why Maxima is in Lisp/ if you want to rewrite, here are some projects

The willingness of people to contribute code in C or
other languages does not require rewriting Maxima in C.


I think that every implementation of common lisp has
a foreign function interface. This means that a
program written in non-lisp (typically C or C++ but
also Fortran or other languages with a similar
calling structure)  can be called.  So if you tell
me you have a superfast superwonderful program that
  you want to attach to maxima, it is possible and
usually trivial to make that call.  The biggest problem
is likely to be the data.  Easiest success is
usually sending an array of floats from lisp to c and
back.
Tougher problem is sending lisp lists etc from lisp
to c and back.  But what are you planning to do with
lisp lists in C that can't be done in lisp?

There is no standard for foreign function calls, but as
an example, I load the tiff (tagged image file format) library
into allegro common lisp by
(load "tifflib.dll")
  and I define corresponding lisp function like this...

(defforeign 'tiffopen :entry-point
   (convert-to-lang "TIFFOpen")
   :arguments '(string string)
   :return-type :integer)

There are similar but not identical routines in GCL, CMU lisp etc.

(It should be clear, however, that it is certainly
possible to do lisp list things in C.  GCL and probably every
other lisp does it all the time as part of the implementation
of Lisp.)

In fact from the perspective of Maxima, the value
of C is that it is a pretty good language in which to
implement Lisp.   But beyond that one should not use
C except for a very very good reason.  Improving performance
by 1% is not (in my thinking) a good reason, but people
can differ.

If you really want to write a bunch of C code to do
computer algebra, my suggestion is to read about and
duplicate the Maple kernel, which represents a stripped
down to the bare bones Lisp system with just enough data
types to implement Maple, and almost no waste.  Originally
they allowed only lists of max length 2^16. That was too
close to the bone and they had to rewrite their kernel to fix that.

Anyway, if you wrote the Maple kernel in a public way,
then Maxima could call it  {not as a separate process, but
as a subroutine} and use it to execute any program written
in Maple.  That way Maxima would swallow up any Maple
computational routine that was not under some kind of
intellectual license.  A much faster way of growing code.

Another possibility would be to write the Maple kernel
in Lisp.  This would actually be much easier, but the
result of simulating Maple data structures in Lisp would
slow it down somewhat.  The extra generality of Lisp
over Maple would cost something; I'm not sure how
much though. An interesting experiment.


A similar thing could be done with Mathematica. In fact
I have a big start on writing Mathematica in Lisp, available
from my web page.  www.cs.berkeley.edu/~fateman

Writing an alternative front end for Maxima is a tricky business.
Symmax or Schelter's Xmaxima  or ....
These are experiments in user interfaces, and regardless of
the programming skill of the implementor, can be good or bad
designs.  One possibility is to take an existing successful interface
and slavishly copy it.  There are several models.  Symmax, or
at least one version of it seemed to copy Mathcad.  I personally
don't care for that, but tastes vary. Mathematica, Maple, and the
commercial Macsyma are similar in many respects.

  I like the traditional script-based interaction, especially since
I can use emacs to manage the script. This is probably old-fashioned.
To the extent that the fancy interface makes this impossible,
I find myself uncomfortable. Even to the extent of managing a
script in emacs and then "batch" loading it into the computer
algebra system.

If you write a GUI, there are ways of doing so IN lisp,
but I think you have trouble with portability. See
  what Schelter did:  he used something like Tcl/TK which is
implemented on several platforms, and then linked to lisp
in another process.
This is not optimal on any specific platform, but it
is pretty good for portability.

PS. You could also look at other packages:  Matlab comes to
mind (or its free clone), could be added to Maxima.



RJF


>