Wolfgang Lux wrote:
> > after some discussion about programming in Curry with Sergio,
> > we want to propose to change the flexible/rigid default in Curry.
>
> after some discussion with Herbert, we do not object to this proposal.
Great!
> While we loose the IMHO nice property, that it is easy to determine the
> evaluation mode of a function by looking at its result type and replace
> it by the quite obscure criterion of being an external function (BTW,
> if_then_else is not an external function), I have to agree that the
> advantages of the change outweigh this particular disadvantage.
Let me clarify this point a little bit. I didn't mean that
functions are flexible if they are not external. I agree that
this might be obscure. Let me reformulate it in the following way:
All functions are flexible by default except for:
- functions with result type IO (your proposal to which I agree)
- functions with evaluation annotation rigid
- some external functions
The behavior of external functions is not described by rewrite rules.
Thus, their semantics must always be described in some other
way (e.g., see the definition of =:= in the Curry report)
and this also includes a specification of the suspension
behavior of these functions. Note that not all external
functions need to be rigid, i.e., suspend on non-ground arguments.
For instance, in the Port library of PAKCS, the external
functions "openPort" and "send" allow uninstantiated arguments.
Thus, one has to look at the definitions of external functions
individually, but this is always necessary and not a particular
problem w.r.t. evaluation annotations.
> However, I suggest a slight change in the proposal. IMHO there is no
> reason to make IO functions flexible, as a non-deterministic IO
> operation
> immediately aborts the program. Therefore, I think functions with result
> type IO should be rigid functions by default as well (and I see no
> problem
> that it becomes impossible to define a flexible IO function with the
> proposed change).
I agree.
> BTW, there is another argument for making defined functions flexible in
> general. It is quite easy to turn a flexible function into a rigid
> function
> but not vice versa. To this end I would suggest to complement the
> proposal by adding the functions
> seq :: a -> b -> b
> ($!) :: (a -> b) -> a -> b
> from the Haskell Prelude to the Curry prelude.
Good suggestion, I agree.
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Sep 09 2002 - 13:16:08 CEST