POS, OOFS, CL v Scheme, etc.

[Henry G. Baker]

> 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.

Yes, one would have to go through the entirety of CL and specify
carefully exactly which functions take and return exactly which
flavors of lists and objects (functional/mutable).  This would also
have to be done in Scheme, if one used that language as a base.

> The idea
> isn't only to allow people to leave data just as they are, but to
> _encourage_ functional programming. 

Even if one didn't care about 'functional programming', per se, one
might still like to take advantage of whatever functional data
structures one was already using.  The problem that I see is that with
the current situation in CL & Scheme, that one is making _every_
object (cons cell/structure/whatever) 'heavyweight' even when quite a
few of these objects can be functional/lightweight.  I only propose to
make explicit which objects are which, since the programmer usually
knows already, but hasn't told the language.

> > 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.
> 
> 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 ;-).

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

The problem with both CL and Scheme 'standards' is that they don't
factor nicely into the 'basic'/'essential' stuff, and the 'library'.
For example, many CL macros _must_ depend upon underlying functions in
order to work, but CL nowhere defines those underlying functions.  I'm
not sure of the goals of CL (I'm not sure who is :-), but the goals of
Scheme seem to be a relatively self-contained 'closed' language with
APL-like goals of cleanliness and elegance.  I suggest that we aren't
interested in a 'closed' language at all, but an organic, growing language
which has a relatively small core.  Various extensions of this core may
approximate Scheme or CL, but that is less of a concern.

-- Henry Baker www/ftp directory URL:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html