Re: Recursive mutexes?

[Tom Lord]

        Tom> Java semantics seem to me much, much nicer for MIMD (just 
intuitively,
        Tom> no elaborate argument).   

        What are MIMD and SISD?

"multiple/single instruction; multiple/single data" -- i.e. ordinary
multi- and single CPU systems.   (I'm not sure anyone really bothers
to say SISD -- I made it up.   People do say SIMD.)

        I like Java's synchronized/notify/wait model very much, but
        how would you express it in Scheme without adding lots of
        Java-ish class declaration stuff?  

The suggestion is that you _do_ look into combining the languages.

One way to do it is kawa-style in which (caution: this is from old
memory) every scheme value is a java object and vice versa.  That
isn't what I was suggesting.

I was suggesting something more layered: Another way to do it is to
have a universe of java-ish objects, shared between threads, and one
store of Scheme objects per thread.  Fine-grain multi-threaded parts
in java-ish; course-grain in Scheme, coordinating via call-outs to
java-ish.  If Guile is currently layered "Scheme over C", this would
make it layered "Scheme over both C and java-ish-over-C".

If Emacs were done that way, for example, you might wind up with
low-level buffers and redisplay in java-ish (redisplay in its own
thread); and scheme-extensible threads for handling user interaction,
subprocess mgt, redisplay customization, etc.

Part of the idea here was to be able to leverage other people's
java-ish implementation work in an easy (heh) way.

Even though it's not a Schemishly minimalist approach, I think this
might actually be a nice model to use when building programs (as in,
"easy to write good, correct, maintainable programs with").


        How would it map onto GOOPS?

Doesn't goops have enough of a MOP to support optimized
representations given restrictions on the optimized types?

-t