So i think we can conclude the following

1) things are not perfect currently. But it requires some huge type class changes to have a better story

2) certain types of data types will need to be newtyped to have instances that play nice with Ryans concurrency work. Thats ok. Theres often good reasons for those "illegal" instances. There is no sound and COMPLETE way to enforce having "good" instances, and thats a good thing, though having more libs work correctly is always a good thing

3) as always, people complain about floats, when the real issue is the current numerical type classes, which are wrong in a number of ways. I hope to experiment with my own ideas in that direction soon. Not worth a boring no ideas worth taking seriously cafe thread


On Wed, Oct 2, 2013 at 2:39 PM, Mike Meyer <mwm@mired.org> wrote:
On Wed, Oct 2, 2013 at 5:18 AM, Tom Ellis <tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:
> Are there examples where application programmers would like there so be some
> f, a and b such that a == b but f a /= f b (efficiency concerns aside)?  I
> can't think of any obvious ones.

Yes, and we already handle it properly:

Prelude> let f = (1.0 /)
Prelude> let (z, negz) = (0.0, -0.0)
Prelude> z == negz
True
Prelude> f z /= f negz
True

This is *not* an "IEEE Floats are weird" thing. Application
programmers want 0.0 to equal -0.0, but -Infinity to not be equal to
Infinity.

Of course, given how many "IEEE Floats are weird" things there are,
you can reasonably consider ignoring this example.

   <mike


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe