Language 'standards' for LispOS

[Marc Wachowitz]

hbaker@netcom.com (Henry G. Baker) wrote:
> As the C language people have pointed out through the years, the
> _literature_ of a language is more important than the language
> standard.  At least in the early going, C was defined more by its
> literature -- the Unix system -- rather than by any 'standard'.

Hmm, from my (and many other people's) experience with porting non-
trivial C programs, I'd rather say that it showed how important it
is (both for implementations and for programmers) to care for a
reliable standard, to avoid the mess of having to run sophisticated
configuration tools and needing lots of #ifdef and portability fixes
and so on. As soon as one looks at the more interesting features,
portability on Unix variants is all but trivial. One can usually get
around those problems, but it's quite annoying and a much larger
source of subtle bugs than I'd like to see with Lisp. Common Lisp
was precisely meant to end this confusion at least partially, and I
suggest to look very hard whether some problem we find with it can
be fixed in a way which conforms to ANSI Common Lisp (which doesn't
mean that programmers which are aware of our extension can't use it;
they should just know the consequences - sometimes this might only
mean that a possibly slower emulation has to be implemented on top
of another Common Lisp implementation; sometimes it may be practically
impossible to run the program elsewhere).

> Similarly, moving from K&R C to ANSI C
> required substantial changes in the matter of declarations, but people
> didn't seem to mind this, since it improved reliability of programs
> quite substantially.

However, many - probably most - changes from K&R C (and offsprings)
towards ANSI/ISO C didn't just prevent something which was correct
before, or give a different meaning to it. Completely _automatic_
conversion is usually possible, in both directions.

I'd expect (and hope) that most - if not all - desired changes can
be made to fit equally well. Where they can't do that, the importance of
a change should be carefully examined. E.g. the identity requirements
in the result of COMPILE-FILE are (for obvious reasons) less strict
than those of simple COMPILE; I suggest we can assume that significant
portions of the system will be compiled with COMPILE-FILE (even if a
"file" might be some kind of object in a persistent system), and we
can live with the more strict rules for the remaining cases.

> As I have pointed out in previous postings, certain irritations with
> Common Lisp have made me suggest what appear to be rather fundamental
> changes to CL.  In particular, I have suggested a whole new class of
> datatype issues -- mutable v. immutable v. linear.

Note that whenever the definition says that modifying something has
undefined effects (like the recently mentioned SYMBOL-NAME; there
are many similar restrictions, e.g. about macro arguments), we can
make the relevant data immutable.

As far as I've read, the definition takes care never to require that
e.g. CONSes or STRINGs are only of one class, but there can be lots
of subclasses of the official CONS and STRING classes, and we might
even perform a CHANGE-CLASS e.g. to a CONS-IMMUTABLE subclass of CONS
in such situations. This, plus appropriately immutability-conscious
standard functions, should already cover quite a lot (I'm not saying
we shouldn't have more control of those things).

> Another area of concern is 'unwind-protect', which I believe is too
> 'high-level' to correctly support a reflective architecture.

I'm curious, what would you like to do differently in that area?

> Of much greater importance, IMHO, is having access to a
> reasonably straight-forward compiler that can be readily modified when
> a crucial optimization becomes important.

We'll need quite a few people for such a task, and I'm not yet sure
about the interest around here. The majority might prefer going with
a mostly-working existing implementation, even if it's complicated
(but maybe CMU-CL's core is even simple; I still didn't look at it).
Comments from those knowing existing compilers reasonably well?

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