RULES and type classes

[Isaac Dupree]

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