-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil Mitchell wrote: > Hi > > I was thinking about this, and I think pattern matching with rules and > class context pretty much _guarantees_ a change in semantics. If you > match on a class constraint, the pretty much only reason to do so is > to exploit that type class. Unfortunately, this isn't safe. > > The user has called a function which explicitly annotates which > classes it requires. The user is completely allowed to write "instance > Ord a where compare = undefined", and they should have a reasonable > expectation that unless Ord a => is in the context, Ord is not > involved. > > So perhaps before you tackle the issue of adding classes to rules, you > need to tackle the issue of getting rules to check what they really > mean...
If it's a type class introduced in the same place as the rule... maybe it's no worse than the strictness-removing transformations we have for ByteString optimizations? (a horrible excuse, I know) What we really need is some sort of library/tool for testing all known instances of type-classes so we can get an overview of which existing instances are a little sleazy, and how. (although that could be difficult. Will quickcheck-style generation be enough to reliably find corner cases like Doubles that are NaN or very large (where e.g. n+1==n), or the effects of Ints having a maximum value?) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDYf3HgcxvIWYTTURAjmuAJ47pUupxyI4mhIdJnfDPXmlW7RWIACdE5Ut UEcshnboU6W952/qQ0WUk4g= =mm1x -----END PGP SIGNATURE----- _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
