Wolfgang Lux wrote:
> In MCC's Success library module, I have introduced two operators
> (==>) :: Success -> a -> a
> and
> (<==) :: a -> Success -> a
I also thought about such operator names, but maybe it is better
to leave such names free for applications in the area of theorem
proving or knowledge representation.
> these operators. And second, it turns out that the prelude already
> contains an even more general operator, which does achieve exactly the
> same effect. Instead of guard (x=:=1) (2+x), you could as well write
> x=:=1 `seq` 2+x
Good point, but I prefer to have a specific operator for this case.
> P.S.: I have another proposal for a minor change in the report
> regarding evaluation annotations. At present, the report says
> (p. 14 in Sect. 3)
>
> A function can be explicitly annotated as rigid. If an
> explicit annotation is not provided by the user, a default
> strategy is used: functions with the result type ``IO ...''
> are rigid and all other defined functions are flexible.
> Functions with a polymorphic result type (like the identity)
> are considered as flexible, although they can be applied like
> a function with result type ``IO ...'' in a particular context.
>
> I have been a proponent of the IO exception because flexible
> evaluation in an IO context does not make sense. However, with
> hindsight, I concede that this was ill-advised because we have
> no concurrency at the level of the IO monad and therefore the
> choice is simply between failing either due to a suspending
> computation or a non-deterministic computation.
No, at least for PAKCS, there is a third possibility:
if an IO action suspends due to a logic variable that
has been sent via an external port, this computation
can be activated if this variable is bound by the external
client/server. This possibility happens in a number of
distributed Curry applications.
> Moreover, the quote from the report is utterly misleading.
> For instance, mapIO has result type IO [b], but its prelude
> implementation is nevertheless flexible. And to add to the
> confusion, sequenceIO is rigid whereas sequenceIO_ is not!
> Therefore, I propose to simplify the default strategy so as
> to make all functions flexible by default and replace the
> quoted sentences by:
>
> A function can be explicitly annotated as rigid. If an
> explicit annotation is not provided by the user, it is
> flexible.
These are good points and I agree to them.
In the case of distributed programming mentioned above,
the suspension is usually enforced by explicit rigid annotations
or by rigidity of built-in functions like arithmetic or (==).
A consequence of this proposal is the addition of some rigid
annotations to IO actions in the prelude, but this is a minor task.
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mi Nov 03 2004 - 09:35:07 CET