In my opinion, even "advanced users" should adhere to The Haskell Report which says that (==) means equality.
Where does the report say that? As far as I can see, the closest quote is this:
The Eq class provides equality (==) and inequality (/=) methods.
(section 6.3.1). The report doesn't explicitly say anywhere that any assumptions about the properties of == are ever made.
If the Report calles (==) an equality method then (==) should implement equality for every Eq instance.
Arguably then, anything which is an instance of Monad should be a monad. And '+' should be addition. etc. etc. Haskell doesn't require any of these to be true, and similarly it doesn't require that every instance of '==' is equality. Cheers, Simon
Am Freitag, 26. März 2004 14:34 schrieb Simon Marlow:
In my opinion, even "advanced users" should adhere to The Haskell Report which says that (==) means equality.
Where does the report say that? As far as I can see, the closest quote is this:
The Eq class provides equality (==) and inequality (/=) methods.
(section 6.3.1). The report doesn't explicitly say anywhere that any assumptions about the properties of == are ever made.
If the Report calles (==) an equality method then (==) should implement equality for every Eq instance.
Arguably then, anything which is an instance of Monad should be a monad.
Of course. But a monad is AFAIK just defined as something that fulfills certain laws, so everything that fulfills those laws is a monad.
And '+' should be addition. etc. etc.
Yes, I'd say that + should only be used for addition. For example, C++ does a bad thing in misusing shifting operators for I/O, IMO.
Haskell doesn't require any of these to be true, and similarly it doesn't require that every instance of '==' is equality.
Well, Haskell doesn't enforce these things. But to my knowledge, the report makes it clear that a Monad instance should satisfy the monad laws. And if the terms "equality method" and "inequality method" in the report don't mean that (==) and (/=) should implement equality and inequality respectively, than their presence in the Report is useless, isn't it?
Cheers, Simon
Wolfgang P.S.: By the way, could you make sure that the citiations in your e-mails aren't messed up? Thanks!
Arguably then, anything which is an instance of Monad should be a monad.
I would certainly argue strongly for that. If it ain't true, then small, irrelevant changes in a piece of code could break. For example, is it safe to make this change: do f y ==> do x <- f y return x I'd hope it would be. (And the change might be useful if I want to insert a check or a debugging printf in the code.) But if Monads don't have to satisfy this axiom, then I can't make a change like this without having to write additional conditions in the documentation or know all possible instances of the code.
And '+' should be addition. etc. etc.
I think it is well accepted that addition in computers is rarely commutative, associative, etc. across the whole range of values.
Haskell doesn't require any of these to be true, and similarly it doesn't require that every instance of '==' is equality.
Though it is, perhaps, worth noting that all standard instances of Eq use observational equality which is plain, ordinary equality for normal values and, if we look at the common extensions, is 'pointer equality' for mutable objects like IORefs. (For abstract datatypes like balanced binary trees, the appropriate equality would probably be to test whether the trees contain the same set of values even if they are balanced slightly differently.) -- Alastair Reid www.haskell-consulting.com
On Fri, 26 Mar 2004, Alastair Reid wrote:
(For [implementations of] abstract datatypes like balanced binary trees, the appropriate equality would probably be to test whether the trees contain the same set of values even if they are balanced slightly differently.)
Of course it is! (And that's what my Standard Proposal specifies by the way...) Robert
participants (4)
-
Alastair Reid -
Robert Will -
Simon Marlow -
Wolfgang Jeltsch