-----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-----