Re: where does mcl fit in?

[bill@cambridge.apple.com (Bill St. Clair)]

>In article <1992Feb11.090256.12470@coli.uni-sb.de>, espen@coli.uni-sb.de (Espen J. Vestre) writes:
>> If a user has several MCL-based standalone apps, would it be possible to 
>> let these apps share a common block of code, to let parts of RTS be a 
>> separate process which could be shared by several other processes?
>>   The grandmother of CLOS, SIMULA, was often claimed to be too bulky to do 
>> serious programming with.  However, the very elegant DEC-10 implementation 
>> had several "shareable high-segments" for compiler and RTS, which were 
>> even shared by all users, which made single Simula programs themselves 
>> require reasonably little disk and memory space.
>>   Another parallell is the MacOS:  Several other GUI, for instance X on 
>> Decstations, require all graphics functions to be linked with each program.
>
>This would be doable with shared library support in the MacOS model. Don't
>ask me when when such support is available :-).
>
>Kent Sandvik/DTS

We've talked about providing the bulk of MCL as a very large init
in order to make very small Lisp applications possible, but this won't
be part of MCL 2.0.

Having shared library support as part of the MacOS model might make
this easier, but only if the OS interface doesn't mandate
a parameter passing mechanism that makes optional parameters and
multiple values painful to implement.

Doing the shared library ourselves shouldn't be hard because the
Mac is one large address space and applications don't move once they
start up. Nobody stops you from jumping off to code in another application.
Of course, if the Mac ever becomes a real operating system, one that
uses the MMU to provide the protection for which it was designed,
then OS support for shared libraries will be necessary.

Common Lisp in the ROMs would be even nicer.

-----
Bill St. Clair
bill@cambridge.apple.com