_at_Michael Hanus
>
> 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 :-(
Now that you say it, there really is no good reason that made me think
function patterns might decouple variable appearances as their agenda is
to treat free variables more like arguments to functions which are
shared anyway.
_at_Sergio Antoy
>
> getAllValues x = findall (=:= x)
> chooseValue (u:v) = u ? chooseValue v
>
> data Color = Red | Green
> Color = Red ? Green
> data Tree a = Leaf | Node a (Tree a) (Tree a)
> Tree a = Leaf ? Node (chooseValue b) (Tree a) (Tree a)
> where b = getAllValues a
>
> test = Node Red (Node Green Leaf Leaf) Leaf =:= Tree Color
That's a very descriptive coding of need-time-choice non-determinism.
But it also imposes a finiteness restriction on the argument, for
example it won't give us
Tree (Tree Color)
_at_Bernd Brassel:
>
> type Generator a = () -> a
>
> Tree :: Generator a -> Generator (Tree a)
> Tree a _ = Leaf ? Node (a ()) (Tree a ()) (Tree a ())
That seems to do the trick. But it looks like it's done in call-by-value
languages, delaying the evaluation of an expression by hiding it under a
lambda. Maybe that's why I didn't come to think of doing this with
call-by-need Curry.
I had just liked to shove the overhead of wrapping arguments with
functions once and forall from application to definition.
Thank you all for your replies!
Best regards,
Sebastian
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Dez 11 2006 - 10:15:55 CET