POS, OOFS, CL v Scheme, etc.

[BRIAN SPILSBURY]

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

I would have to agree, adding immutablity as a large part of the core
of the language is a good idea, it allows lists to be collapsed and
re-implemeneted (possibly as type-specialised) arrays.

When a style of threading is chosen, that needs to go in at the roots of
the implementation, otherwise you'll have nasty problems, its very
hard to retrofit threading to a non-trivial system.

And it goes on, persistence, security issues, etc.

I think we need a new, but very small dialect of lisp. One simpler
yet more reflective than CL (and CL is reflective enough to mutate into CLOS
for example). One capable of supporting a CL implementation over the top
or a scheme implementation.

If we can agree that we do need a new dialect then we can stop squabbling
over which dialect to use, and start stealing the more useful bits of
what's around and tested, and then we can shout at each other about what
a minimal dialect needs to support features our own favourite features. :)

Anyone willing to hack up a simple (and probably broken) blueprint
for such a beastie as they see it?

Brian