Hrvoje Niksic <hniksic(a)srce.hr> writes:
Olivier Galibert <galibert(a)pobox.com> writes:
> Do you realize that if external third party C modules become the
> rule, we can't change anything to the Mule implementation or the
> lisp system? That we couldn't have ported to win32? That the "gung
> ho" changes would have been impossible to make?
I don't think we need to worry about binary compatibility at all. It's
clear that, given the current state of affairs, it is impossible to
maintain anything close to that.
As for the source compatibility, the only sane way of handling modules
I can think of is to define and document a *minimum* set of primitives
that are allowed in modules. But not even these should be cast in
stone, I think -- modules are pretty much meddling with the
implementation (more convenient meddling, but still meddling), and we
should always have a right to change it.
Even if we do not move some things out into loadable modules, I think it
would be nice to restructure a lot of the source code for the next major
release (after 21.2, whatever that may be) so that things are a little more
isolated. Move stuff into (redisplay|event)/(x11|win32|tty) type of
thing. This way, if someone steps up to `take over' officially maintaining
a piece of code, it can be clear who owns what, and can make it easier for
someone to drop in a complete new code drop into CVS.
Having everything in src/ bugs me. I tend to go the opposite extreme. Our
product at aventail is spread over gobs of directories. Our autoconf
script spits out 82 whole makefiles, 5 fragments, and a couple of support
scripts. :)
-Bill P.