Sorry for mistaking the previous statement. It is my impression that GCL is
the primary delivery vehicle for Maxima. Certainly it is the case for my
experience using it under windows. (I am perhaps the only person who
occasionally runs the core Maxima under Allegro Common Lisp, or its free
version, Allegro 'Express'. I do so for various technical reasons: some
programs work, or work much better, with Allegro than GCL; the programmer's
interface is, I think, better. I can do experiments that are implausible
with GCL, because even though GCL is in theory "open source", it seems
foolish for me to modify to make a separate branch, as well as difficult
etc. when the Allegro implementation already has the features I need to
compare data structures, or algorithms, or multiprocessing or whatever.
Could I do the same experiments with CMUCL? Maybe it is closer to Allegro,
or possibly even better. I haven't tried using CMUCL for several years, and
the Sun system I have is old and slower than Intel machines I have. ).
Given that orientation, it seems to me that anyone planning a package
intended to be part of Maxima for the majority of Maxima users should
implement and test on GCL. Given a GCL version, it runs on both *nix and
windows and any other place GCL runs. Maybe it will run elsewhere, but if it
doesn't, we can still use it on GCL. So anyone using foreign functions for
Maxima, with the intention of delivery, should write to use the FFI that
works on GCL. This still allows others who favor another lisp to port it to
CFFI or to the more specific versions in other implementations if they wish.
It does not seem to me fair to the author or the potential users of the
program to place an additional requirement to the Maxima contributor to make
sure his program works on all Lisp implementations. I certainly don't
require testing on Allegro Express.
RJF