POS, OOFS, CL v Scheme, etc.

Marc Wachowitz mw@ipx2.rz.uni-mannheim.de
Mon, 12 May 97 18:24:04 +0200

Brian Spilsbury <zhivago@iglou.com> wrote:
> Um, I don't see why you need any surgery at all. Just define types
> without mutators.

Of course, that would be trivial - you can already achieve that
with standard Common Lisp. However, Henry Baker's proposal, if I
understand him correctly, goes beyond that. Merely preventing the
programmer from modifying some stuff is nice, but the real benefits
would be from the improved semantics and additional optimization
opportunities, meaning that the relevant standard functions should
return immutable data which can be shared or cloned at will. This
in turn requires clear conventions to get either "pure" data or
"normal" (as current) data from the relevant functions. The idea
isn't only to allow people to leave data just as they are, but to
_encourage_ functional programming. If that doesn't have noticable
consequences for the structure of the system, it's mostly worthless.
While one can certainly program without many side effects in Common
Lisp, it seems they are much more deeply embedded in the notions how
Common Lisp, CLOS etc. work.

> I'm not really pushing CL here, but there are reasons against scheme
> I'd prefer a proto-lisp which could be refined into either at a later stage.

Scheme isn't exactly a big language, so why not use it as already some-
what extended proto-Lisp? There should be some provisions for working
with more low-level data (like suggested in the mentioned CritLisp), and
most of R4RS could easily be at the library level (whether procedural or
syntactic); the specification already alludes to such an understanding.

> Then at least you'd have the option of something standard without making
> the possible mistake of C++ - Lets base an oop language on something
> never designed for it - be wary of basing an os on a dialect never
> really designed for it.

Well, Scheme's "advantage" here is indeed that it's small; it's not hard
(and IMO conceptually relatively clean) to extend the language seamlessly
towards object orientation, without hurting RnRS compatibility. Remember
that various incarnations of CLOS have been put on top of pre-Common Lisp,
too - and pre-CL was a quite hairy and heavy beast compared to Scheme
(some might argue it still is ;-).

Personally, I don't have anything against starting from scratch, but from
a practical viewpoint, it seems to be preferable to start with an existing
yet not too complicated core (assuming it's mostly right - which I think
Scheme is), with existing implementations, experience, documentation etc.
The focus on mostly extending (upwards and downwards) an existing system
may also help to prevent superfluous nitpicking about trivialities: If one
has an idea how to proceed, one will often be able to test it with little
effort in an existing implementation, since there are so many of them that
one will most likely find one which can easily be hacked for that purpose
(even if the result won't necessarily always be hight efficient).

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