John Lloyd wrote:
> 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.
I understand by concurrency the possibility to have different
threads of computations which may be evaluated in parallel.
"Residuation" causes different threads of computations
since if a function call residuates, you must proceed
at another point in your program in order to make a progress.
Thus, you immediately obtain different threads of computation
and, consequently, a concurrent behavior.
However, my original motivation for adding residuation was
to provide a common basis for FL languages. Moreover, residuation
is also used in current Prolog systems and has been shown useful
to make non-deterministic computations more efficient ("passive
constraints"). If one allows to residuate a function call,
one has to define where to proceed in such a case, and this
is exactly the purpose of the concurrent conjunction operator.
Later, it turned out that this simple model is also sufficient
to accommodate Goffin or Eden programs. Since Goffin already provides
nice features for concurrent computations, additional features are not
needed (see Manuel's comments). In fact, one of my students develops
an implementation of Curry in Java (to be more precise, Pizza),
where the concurrent computation threads are mapped to different Java
threads. If Java executes these threads on different processors,
they really run in parallel.
Best regards,
Michael
Received on Fr Jul 04 1997 - 18:46:00 CEST
This archive was generated by hypermail 2.3.0
: Do Feb 01 2024 - 07:15:05 CET