Wolfgang Lux wrote:
> 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.
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.
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Nov 15 2004 - 18:18:12 CET