Re: Evaluation Annotations: are they needed?

From: Wolfgang Lux <wlux_at_uni-muenster.de>
Date: Mon, 15 Nov 2004 14:17:00 +0100

Bernd Brassel wrote:

> Is it not as easy to write
>
> f = f' (rp x1) ... (rp xN)
> where
> f' <old definition of f>

This depends. Consider the addition of type classes to Curry
(as, e.g., in Diego Berrueta's Zinc compiler). In the presence
of type classes, the functions (==) and show are no longer
primitive functions, but defined by the user (at least for
the non-standard types). And you certainly don't want to
recommend writing the Eq and Show instances in the above way.
In such a system you certainly need some kind of annotation
-- unless, of course, you are willing to live with flexible
instances of (==) and show, which is not very reasonable IMHO.

Maybe Julio's proposal is not general enough to handle this
case (after all, one really should be able to annotate
methods like (==) in their class declarations, which means
that one does not known the actually types of the arguments);
but at least an eval annotation in a type class could force
the user to provide an eval annotation in the concrete
instance declarations. For that reason I disagree with
Michael's comment in a different posting (though I'm taking
this somewhat out of context):

> However, this need not to be done in the program code.
> For instance, the documentation of a function is usually
> a good place where this information could be shown.

The point of annotations in the code is that they have an
effect on the code generated by the compiler and can be
used for enforcing particular obligations on the user,
like the one suggested above.

Bernd also wrote:
> Why do we need syntactic sugar for this? Anyway it seems to me that
> you rarely realy need all of the arguments of a function to suspend on
> free variables. It might even lead to unsuspected behaviour. For
> instance, if you want to formulate if_then_else, writing
>
> if_then_else eval boolRigid rp1 rp2
> if_then_else True x _ = x
> if_then_else False _ y = y
>
> would lead to a different behaviour. Or should we be able to write
> just if_then_else eval boolRigid, without rp1 and rp2? What if we need
> only the second argument to be rigid?

No problem. You can simply consider the identity function as a
(trivial) rigidness projection and write

   if_then_else eval boolRigid id id

Eventually one might also use an underscore as syntactic sugar for
that in order to emphasize that one is not really interested in those
arguments:

   if_then_else eval boolRigid _ _

Regards
Wolfgang


_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mon Nov 15 2004 - 16:57:52 CET

This archive was generated by hypermail 2.3.0 : Thu Sep 19 2019 - 07:15:06 CEST