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
etc.
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).
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Di Nov 16 2004 - 09:40:10 CET