[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MCL modules (was : MCL Futures)
- To: firstname.lastname@example.org
- Subject: MCL modules (was : MCL Futures)
- From: Vincent Keunen <nrb!keunen@relay.EU.net>
- Date: Wed, 15 Jul 1992 15:35+0200
- In-reply-to: <2596.2A63CD0E@zorro9.fidonet.org>
- Reply-to: 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
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
of MCL could be useful if callable from _native_ Mac applications through
trap calls (best, because that makes the functionality shareable among
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?
Keunen Vincent Network Research Belgium
R&D, Software Engineer Parc Industriel des Hauts-Sarts
email@example.com 2e Avenue, 65
tel: +32 41 407282 B-4040 Herstal
fax: +32 41 481170 BELGIUM
- MCL Futures
- From: David.Lamkins@p14.f640.n101.z1.fidonet.org (David Lamkins)