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 <m...@mired.org> wrote: > On Wed, Oct 2, 2013 at 5:18 AM, Tom Ellis < > tom-lists-haskell-cafe-2...@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 > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
