a proposal featuring a bug

From: Sebastian Hanowski <seha_at_informatik.uni-kiel.de>
Date: Mon, 11 Dec 2006 08:45:21 +0100

_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

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