
Hi On 13 Mar 2008, at 23:42, kahl@cas.mcmaster.ca wrote:
Conor McBride
responded to my comment: (mapMonotonic should of course be removed, too, or specified to fail (preferably in some MonadZero) if the precondition is violated, which should still be implementable in linear time.)
What's wrong with mapMonotonic that isn't wrong with, say, sortBy?, or Eq instances for parametrized types?
Prelude> :m + Data.Set Prelude Data.Set> toAscList $ mapMonotonic (10 -) (fromList [1 .. 5]) [9,8,7,6,5] Prelude Data.Set> 5 `member` mapMonotonic (10 -) (fromList [1 .. 5]) False
Something's certainly wrong there!
But nothing out of the ordinary: garbage in, garbage out. Happens all the time, even in Haskell. Why pick on mapMonotonic? Prelude Data.List> sortBy (\_ _ -> GT) [1,3,2,5,4] [4,5,2,3,1] Prelude Data.List> sortBy (\_ _ -> GT) [4,5,3,2,1] [1,2,3,5,4] I guess there's a question of what we might call "toxic waste"---junk values other than undefined. I think undefined is bad enough already. So the type system can't express the spec. I don't think we should be casual about that: we should be precise in documentation about the obligations which fall on the programmer. Some dirt is pragmatically necessary: we shouldn't pretend that it ain't so; we shouldn't pretend that dirt is clean.
Before we can talk about what == should return, can we settle what we mean by = ?
``='' is not in the Haskell interface! ;-)
No, but "is" is in the human interface!
Therefore, I talked only about (==).
Ah, but you talked about things. Which things? Is one of the things you talked about the same as (==)? the same as (flip (==))?
The best way to include ``='' seems to be the semantic equality of P-logic [Harrison-Kieburtz-2005], which is quite a heavy calibre, and at least in that paper, classes are not yet included.
I expect it's hard work. It's hard work in much better behaved systems. My point is that it's worth it, in order to facilitate more meaningful discussions. All the best Conor