POS, OOFS, CL v Scheme, etc.

[Henry G. Baker]

> It's probably true at least for old dialects. I'm not yet convinced
> whether what we're discussing here really needs to create yet another
> incompatible dialect, rather than a clean extension. For Common Lisp,
> its size, complicated interactions between various features and a very
> detailed definition are a problem, but Scheme still appears to be a
> sound base, leaving much room for fixes (e.g. the report does even
> tell explicitly that it doesn't presume to specify the behaviour of
> implementation-dependent extensions, mentioning EQV? and "uninterned
> symbols" in one example).
[snip]
> Neither threads nor reflective capabilities would imply non-conformance
> (of the implementation) with the standard, as far as I can tell; just
> make sure extensions live in a different package, or extend a standard
> feature in an accepted way (e.g. a function which understands a larger
> variety of arguments and does interesting things with non-standard types).
> 
> -- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>

Surely you're dreaming if you think that adding threads to CL can be
done in a 'conforming' way by simply adding another package.  If you
thought that adding immutable cons cells required going through the
entire CL book and deciding for each function about what kinds of cons
cells it would consume and emit, you have the same problem in spades
with something like threads.  If you don't do this, then you get into
the ridiculous situation that Ada finds itself, wherein Ada has both
tasking (threading) and I/O, but _nowhere_ does it define how these
two interact!  There are _no_ requirements on whether multiple threads
can access the same I/O stream, or what the results are if they do.
One presumes that simply crashing the system falls within the Ada
standard.

But then suppose you _do_ go through and define for every CL primitive
how it is supposed to interact with threading.  Suppose that you find
yourself in the situation where any _reasonable_ definition requires
so much locking that certain previously efficient primitives become
pigs, and hence unusable.  What do you do?  Live with it, or fix the
language?  I suggest that fixing the language is a better solution.

CL was merely a 'work in progress', and since they never solved
certain hard problems including OODBMS and threading, there is no
reason to suspect that the CL committee made all the right choices.

For example, the LispM used 'stack groups' for its threads, and these
turned out to be pretty 'heavy weight', due to the requirement to bind
and rebind a bunch of shallow-bound 'special' variables.  I'm not sure
that this is such a hot idea in 1997.  Therefore, since CL was based
substantially on the LispM model, I'm not so sure that CL itself can
survive without change into 1997 LispOS.

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