Scheme vs. CommonLisp vs. the World

[Marc Wachowitz]

Kelly Murray <kem@Franz.COM> wrote:
> Yet another BTW, I recall Scheme only has arrays of type "t".

Right, if we want to use Scheme, we'll have to define a library
for low-level programming, and probably a way to declare types
for efficiency where the compiler can't figure it out by itself.
However, most of that could remain conceptually very simple, and
not introduce the whole complexity and ambiguous nature of Common
Lisp's type specifiers. Experiences from the ML-Scheme interface
camp might also be useful for that purpose (i.e. look whether we
may want to make something explicit which they try to infer but
can't do easily/reliably).

> I think it is mostly removing or tweaking CL things, rather than
> wholesale replacement.

If we're using one of the established Lisps at all, we should go
the whole way, enabling compatibility in both ways for those areas
where the standard features are sufficient, and extening the base
in a way which doesn't conflict with standard programs (except for
using a few module/package names, obviously). Defining some kind
of kernel for better understanding and bootstrap simplicity is one
thing, creating lots of incompatibilities without need is another.

Something like "yeah, we do have Common Lisp, except bindigs and
CONS cells are immutable, you'll need LET-LOSE and CONS-PIRACY for
mutable bindings/lists, and we've thrown out complex numers and
packages, but in return you can trap every access to your symbols
with some special extension of our cool long-term memory system"
would be a bad idea, IMO ;-) If we need to be truly different, we
should at least "do it right" from the ground up, and not create
a kind of Perl with parentheses. Otherwise, conform to standards,
and put extensions cleanly around them.

> Using destructive list operations is ancient-style lisp coding.

CONSes are only a small part of the question. What I'd prefer is
a model where almost everything (including object oriented meta
level programming) can be done in a mostly functional style, but
that isn't meant to prevent side effects where the programmer
considers them useful. As Henry Baker wrote, clarify what's what.

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