Sebastian Hanowski wrote:
> ...
> But the recent extension of Curry with /function patterns/ introduced
> variables which are bound to unevaluated expressions when defined
> functions are applied to them in pattern expressions on the left-hand
> side. One can thus exploit run-time-choice non-determinism for the
> encoding of type constructors.
>
> Tree (id a) = Leaf ? Node a (Tree a) (Tree a)
>
> > Node Red (Node Green Leaf Leaf) Leaf =:= Tree Color
This is a nice proposal but, first, I was surprised that
function pattern should provide the opportunity to encode
run-time choice. Since function patterns are interpreted
as an abbrivation of all possible patterns obtained by
narrowing the function pattern, the above definition should
be equivalent to
Tree a = Leaf ? Node a (Tree a) (Tree a)
Thus, run-time choice cannot be encoded in such a way.
I guess you have tried PAKCS and, indeed, PAKCS
has a different behavior. However, this is a bug in the
implementation and not a feature :-(
The current implementation does not implement sharing for
function pattern variables which is now corrected in the
next release to come.
Thus, thanks for your example that showed a bug in PAKCS!
On the negative side, you have to look for another solution
for your problem...
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Dez 08 2006 - 13:06:13 CET