Concurrency in Slate

[Brian Rice]

At 07:50 PM 6/5/00 -0700, Alex Kravets wrote:

>Brian, first of all, I'd like to express my admiration for
>the ambitious project you guys are undertaking with Slate.

Thanks. Maybe someday I'll actually be making money on this. ;)

>I'm extremely impressed with the set of ideas you decided to
>borrow from other experimental languages to implement in Slate.

Again, thanks. I'm really pushing hard to make it come together right, and 
there have been quite a few delays due to trying to satisfy Tunes HLL 
documentation to the nearest extent possible. There will be a new set of 
documentation soon that will provide a very conrete explanation of all the 
ideas I have compiled and what that will translate to for the user of the 
language and how an implementation can satisfy the specification. (This is 
very time-consuming, as you might imagine. We're also migrating the Tunes 
site documentation as well as the Slate and Arrow documentation to a new, 
more flexible system.)

>I noticed that in the Slate semantics page you state:
>
>Update: The option for a lazy functional language to use demand-driven
>concurrency control in a way that makes concurrency and distribution issues
>transparent and subject to data-flow dependencies. In this way, everything
>is a thread that can be orthogonally-distributed. This allows for all of the
>concurrency semantics one could wish for with a clean basis.
>Is it correct to assume that you decide to adopt a wait-by-necessity model
>akin to that proposed by Eifell // at:
>http://www.eiffel.com/doc/manuals/technology/concurrency/
>also discussed within the Merlin Project at:
>http://www.google.com/search?q=cache:www.lsi.usp.br/~jecel/selfdiff.html+wai
>t-by-necessity&hl=en

Yes, that's correct. However, there's of course some indeterminacy that we 
would like to open up to the programmer through an aspect of the reflective 
interface (the MOP). Of course data-flow dependencies provide you a 
framework of constraints for code scheduling, but there should be a way to 
open up the mechanisms of the scheduling and change them. For technical 
detail, look at papers on term rewrite as a meta-language for expressing 
various modes of concurrency specification (up to and including real-time 
systems specifications).

>Cheers ...
>
>Alex Kravets, Lead Architect
>http://www.FirstLook.com/

Thanks,
~