MCL modules (was : MCL Futures)

[Vincent Keunen <nrb!keunen@relay.EU.net>]

    Date: Wed, 15 Jul 1992 05:13+0200
    From: David.Lamkins@p14.f640.n101.z1.fidonet.org (David Lamkins)

    [...]

    7.1. I'd like to hear whether portions of MCL could become OS modules in 7.1.
    Think of this: there are thousands of Mac application developers that have to
    face tricky problems in dealing with the Mac toolbox's Memory Manager. How
    many
    would give their left arm to have MCL's memory manager at their call? No more
    worry about memory leaks... It wouldn't be very hard to imagine how other
    parts
    of MCL could be useful if callable from _native_ Mac applications through
    either
    trap calls (best, because that makes the functionality shareable among
    multiple
    apps) or as MPW libraries.

MCL developers: Is it a silly idea to imagine that MCL could be broken
up in modules.  I known some would be dependant, but maybe not all.  It
would be nice to a an inspector module, for example, that could be
excluded from the environment if one is sure it is not needed (how to
know?...).  Or, some MCL modules could be used as stand-alone units if
one is sure these modules are self-consistent...

Is the idea of a more modular lisp environment a dream?

vk
===============================================================
Keunen Vincent                  Network Research Belgium
R&D, Software Engineer          Parc Industriel des Hauts-Sarts
keunen@nrb.be                   2e Avenue, 65
tel: +32 41 407282              B-4040 Herstal
fax: +32 41 481170              BELGIUM
===============================================================