Nice examples.
> Probably the most spectacular failure would be f $!! map id because it uses (=:=).
While experimenting with $!! I may have found an MCC bug. If we define
ignore1 _ = \x -> x
ignore2 _ x = x
PAKCS can distinguish ignore1 from ignore2 but MCC cannot:
pakcs> (id $!! ignore1 failed) success
Result: success
pakcs> (id $!! ignore2 failed) success
No more solutions.
cyi> (id $!! ignore1 failed) success
No solution
cyi> (id $!! ignore2 failed) success
No solution
MCC seems to transform ignore1 into ignore2 otherwise the failure
would be ignored in the first example.
I would prefer if both 'ignore1 failed' and 'ignore2 failed' would be
observably indistinguishable from 'id'.
> keep in mind that a partial application may occur deeply nested inside the argument of (=:=) or ($!!), which could lead to rather non-obvious failures.
I think the failures would only be non-obvious if it is unclear
whether a unified expression contains a function or not. Abstract data
types, where users don't know the representation seem problematic. For
example sets can be implemented as data structure or as characteristic
functions and these implementations would behave differently regarding
constraint equality if it always fails for functions.
But note that the Curry Report specifies constraint equality only for
data terms. Implementations are free to implement constraint equality
on functions in an arbitrary way and every program that relies on a
specific way is compiler dependent. The Parser library is a nice
example for such a compiler dependent program.
Sebastian
P.S. I found another MCC bug:
cyi> (\_ -> \x -> x) failed success
cycc: internal error: arity x.4
I am using MCC 0.9.11 on a 64 bit Ubuntu Linux.
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mi Jun 20 2012 - 17:56:16 CEST