David,

> >> My one reservation is the threads.  ...

I wonder why - have you ever looked at Squeaks threads?! Here are few
comments on your suggestions.

> There's several ways to have good support for threads:
> 
> 1) no stupid restrictions on how many.

In Squeak there are none. There are a few implications for the garbage
collector (these are of highly technical nature and solutions have been
proposed) but I've been using plenty (e.g., >10k) of threads in Squeak
with no problems whatsoever (err ... besides debugging them ;-)

> 2) locks should be fast -- ideally, about as fast as a
>    bus-locked compare-and-swap (or load-linked/store-conditional)
>    to acquire or release one. 

In Squeak, locks are almost as fast as that. I once measured the
overhead of a thread switch (which is what really counts here since if
the lock can be aquired the entire operation is basically zero cost) and
the it's roughly the speed of four message sends. In other words, if
your machine makes a million msg sends per second you can do a quarter
million process switches per second easily.

> They should also be pretty near
>    fair (FIFO) in how they give competing threads access to the
>    lock. 

In Squeak, they are.

> Note that this is independent of how "lock" is spelled
>    in the source language -- when you rip away the abstractions,
>    there's mutual exclusion at the bottom, and threads are competing
>    for access, and it should be fast and fair.

That's exactly the case in Squeak.

> 3) there should probably be a useful set of different
>    lock types provided. 

Which types? We only have one but everything else can be trivially
added. Not at the same speed but once the functionality is there it
could be moved down to the VM level and be handled more efficiently
there.

> 4) there needs to be a consistent/complete set of primitives.

What does 'complete' mean in this context?

> 5) don't do what Java did -- don't make "any object" also able to
>    function as a lock. 

We don't. There's class Semaphore and everything is implemented here.
Note that there are a few advantages to having every object be able act
as a lock - it frees you from adding the necessary access wrappers in
each and every function.

> 6) wouldn't hurt a bit to go look at Doug Lea's work with Java.
>    I regard most of what he did as "Java needed this, but they left
>    it out, so here is something that does what you need and works".

Since I haven't looked at it, can you elaborate a bit on what he did?

Cheers,
  - Andreas