Hi Jan, On Tue, Apr 09, 2013 at 01:32:33PM +0200, Jan Stolarek wrote:
Thanks for pointing me to earlier discussions on this subject - they are enlightening :) One particular argument "against" seems to be very convincing to me:
"From a language design point of view, it should be noted that turning non-left linear patterns into ones with == guards elevates the class Eq to built-in status - but the compiler has no semantic control over it."
Yes, I can see the point, but in the case of Haskell with its ability to automatically derive the Eq instance, there's some kind of semantic control, and if an user writes a nonsense Eq instance, than he just really asks for some hurting ;).
Regarding the possibility of making accidental mistakes during refactoring etc. This could be implemented as a language extension, requiring explicit LANGUAGE pragma. So people using it would know they have semantics slightly changed and need to be aware that there is a possibility of making these kind of mistakes.
I'm a bit torn between all these GHC extensions. If your code doesn't compile, did you really made a mistake or just forgot to include a GHC extension ... But I also have the feeling, that the extension perhaps might not be worth it, because the difference between foo x x = ... and foo x y | x == y = ... is just IMHO too small. Greetings, Daniel