Concurrency

From: John Lloyd <jwl_at_cs.bris.ac.uk>
Date: Fri, 4 Jul 1997 15:00:39 +0100 (BST)

Manuel writes:

> What I am missing is the *reason* for supporting concurrency in Escher
> and Curry (I mean, apart from the fact that it is a cool thing to do).

Oh, the motivation for Escher coincides very much with the motivation
for Concurrent Haskell, i.e. that there are important applications where
explicit concurrency in the language is useful/vital. Parallelism wasn't
at all a motivation for me.



> As I understand Michael, the reason for the introduction of two
> different types `Bool' (the well known two-valued data type) and
> `Constraint' (the type of concurrent constraint expressions) is the
> same as in Goffin (where we call `Constraint' simply `O').

My earlier remarks re. Boolean vs. Constraint were based solely on what
would be useful to build a constraint solver. For that purpose, the apparatus
introduced in Curry didn't seem to me to be needed. If it's also needed
for concurrency then that's a different point (which at the moment I don't
understand well enough to comment on). But it does seem we agree that
"residuation" on its own isn't enough to get concurrency. Goffin/Curry add
one mechanism, Escher adds another completely different one to get concurrency.
That's fine. It seems like it would be interesting to explore at some stage
the various possibilities of these two approaches.



> The reason why you have difficulties to regard the Goffin-model as
> concurrent is because you are not willing to adopt two boolean types
> (see above), which carry different operational interpretations. On the
> other hand, you agree to adopt the new type `IO' (and the operators
> that come with it) to introduce some dedicated operational behaviour...

I didn't have any difficulties with the Goffin model. I was merely saying
residuation wasn't enough. I think we agree here - see above.

John
Received on Fr Jul 04 1997 - 16:46:00 CEST