Re: Evaluation Annotations: are they needed?

From: Wolfgang Lux <>
Date: Tue, 16 Nov 2004 09:13:34 +0100

Michael Hanus wrote:

> However, before introducing such annotations, one should carefully
> consider the number of applications where they are useful and balance
> it with the introduced disadvantages by designing a more complex
> source language. For instance, the original design of Curry
> had an explicit annotation for definitional trees in order to
> allow a mixture of flexible and rigid cases. Later we saw that
> usually nobody uses this option so that we removed it.
> Similarly, previous versions of Curry had different pattern
> matching modes (left-to-right, optimal, everything flexible or rigid
> in a module). After we recognized that nobody used it (or at least
> the same effect can be obtained by a slight change in the program),
> we removed it. All these changes led to a simpler language design.
> For the same reason, I like your proposal to remove the evaluation
> annotations since they seem unnecessary in practice: after your
> initial proposal, I constructed a preliminary system without
> evaluation annotations but an "ensureNotFree" primitive.
> And it turned out that I have to use it only at two places
> (in the prelude.if_then_else and in the Port library).
> It is not necessary to use it in any application program
> (and you can imagine that I have many of them).
> Thus, I would avoid introducing new constructs if they are
> not used in practice.

I completely agree that we should try to keep the language as
simple as possible. However, my point is that in an extension
with type classes you will certainly need it much more often in
order to ensure that all user defined implementations of (==) and
show are actually rigid. IMHO, you cannot seriously expect a user
to write the following code.

   instance Eq Bool where
     b1 == b2 = equal (ensureNotFree b1) (ensureNotFree b2)
       where equal False False = True
             equal False True = False
             equal True False = False
             equal True True = True

   instance Eq a => Eq (Maybe a) where
     m1 == m2 = equal (ensureNotFree m1) (ensureNotFree m2)
       where equal Nothing Nothing = True
             equal Nothing (Just _) = False
             equal (Just _) Nothing = False
             equal (Just x) (Just y) = x == y


I really do believe that we need some kind of evaluation annotation
for that (probably in the class declaration in order to ensure that
*all* instance implementations are evaluated rigidly).


curry mailing list
Received on Di Nov 16 2004 - 09:40:10 CET

This archive was generated by hypermail 2.3.0 : Do Jun 20 2024 - 07:15:07 CEST