POS, OOFS, CL v Scheme, etc.

[Marc Wachowitz]

hbaker@netcom.com (Henry G. Baker) wrote:
> The problem with both CL and Scheme 'standards' is that they don't
> factor nicely into the 'basic'/'essential' stuff, and the 'library'.

It looks like R5RS is going to make such a distinction explicit for
its procedures, and provide macros (by way of the adopted high-level
syntax-rules from the R4RS appendix) for derived expressions.

Adding primitives for explicit fixnum-with-carry computations, bit-
level stuff etc., probably shouldn't be a problem - at least there'd
be a core language which programmers could hope to understand and
master with acceptable effort - whereas for CL the initial problem
is already to distill a reasonably complete model of system operation.

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

I'm not sure what exactly you mean here with "closed" - adding lots
of extensions has never been a problem for Scheme implementors. What
has been a problem for Scheme programmers so far is a way to reuse
lots of non-trivial source code from various authors in an organized
way (i.e. lack of interface conventions and/or technology), with about
as many emulations of modules and object orientation as there are
contributors).

Again, I'm not against starting fresh; I'm just trying to clarify the
various alternatives and trade offs. Unless there's a real hindrance
in adopting Scheme or Common Lisp (or maybe improved EuLisp), I suggest
compatibility with established languages is worthy of consideration.
The Lisp world is already small enough without more fragmentation than
necessary for technical purposes.

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