POS, OOFS, CL v Scheme, etc.

[Marc Wachowitz]

hbaker@netcom.com (Henry G. Baker) wrote:
> things in CLOS would need fixing, and especially the Xerox CLOS
> implementation which makes it impossible to properly initialize a
> functional object.
>
> One solution to the initialization problem is to incorporate _both_
> linear/unique types and functional/readonly types at the same time.
[...]
> The most obvious problem is to decide whether 'cons' returns a
> functional or a non-functional list object.  I would vote for
> _functional_, on the grounds that it would trap when you tried to
> modify such an object, and would force you to think about how it is to
> be used.

Obviously, if we're going towards this, we'll have to do a major
surgery of the base language and will essentially need to think
about the semantics of all existing functionality. If we're to
do this, I'd indeed suggest to extend Scheme rather than Common
Lisp, since a sufficiently careful and exhaustive review and re-
implementation of Common Lisp would probably be beyond our short-
term capacity (note that this would affect the optimizer deeply).
On the other hand, Scheme is small enough to do this, and would
also be more suitable in other ways for a "kernel Lisp" approach
(or does anyone consider Common Lisp's state-based and mutable
package system to fit into a mostly-functional environment? ;-).

To preserve the value of existing knowledge, source code etc., I'd
suggest to conform to R5RS (supposed to be published soon; I know
that at least R4.95RS is already done). Since we need an expressive
module system anyway, it would also be the right approach to adding
such extensions: Package definitions in modules according to their
conceptual relations, and combine some useful default configurations
into new modules (e.g. one with exactly the RnRS name space, or one
completely without mutators, and so on), allowing renaming and re-
export. Module top-level bindings should be read-only from clients,
and the compiler could easily determine if a definition might be
re-assigned within the module (I doubt whether explicit syntax for
mutable vs. immutable bindings is really worth adding).

Rather than deciding _at_the_language_level_ whether e.g. CONS is
going to deliver read-only non-identity-preserving storage, we may
as well introduce various differnt (yet similar) procedures for each
allocator, treat the results as different types (both subtypes of
what's recognized by PAIR? and friends), and use generic procedures
for all procedures working on already existing objects.

Note that literals are already specified as immutable, and sharing is
permitted, though arbitrary cloning definitely isn't. If we think we'll
need such cloning, we can make it a property orthogonal to immutability,
and allow the programmer to declare that a module doesn't care at all
about the identity of the results of its literals.

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>