Re: Import and Export

[Joseph.Ginder@cmu-cs-spice.arpa]

The CMU approach does allow other languages to make remote procedure calls
to Common Lisp.  I don't see that the issue of a minimal kernel is
particularly relevant to this.  For a foreign language to make calls on
Common Lisp does not require that the Lisp it is calling have some specific
functionality more than that it is there and can be called.  I certainly
don't expect to define what functions are avaliable in fortran libraries in
order to define a foreign funcall mechanism for Common Lisp; I don't see how
anything different is implied by the reverse situation.

When we are concerned about supplying a minimal lisp for some application at
Perq (and CMU), we just load whatever application stuff there is into a lisp
and disembowel the lisp in such a way as to make all of the Common Lisp stuff
that isn't used available for GC.  We then force a GC and save the new,
application-specific lisp core.  The real problem then, becomes knowing what
minimal stuff the foreign language will call in order not to disembowel too
much.  I don't really have much of a feel for how important such minimal
lisps are; I think this a task of the subset committee.  

To the subset committee: I can imagine applications where the delivery
vehicle for a lisp application is a fairly limited piece of hardware; is a
subset appropriate or would the method described above be acceptable?  We've
found that very straightforward methods of reducing a lisp core's size
result in dramatic space reductions; more thoughtful approaches should
result in really small lisps for delivery of applications without requiring
a specific minimal subset (although a "kernel" subset might be useful for
other reasons).

--Joe