I am somewhat skeptical of this extension; guards seem to work, and while I use syntax extensions somewhat liberally I am not certain this provides enough benefit to restrict code to GHC. I used it extensively in Erlang, but I find myself doing much less pattern matching in Haskell.
That said, I am unconvinced by most of the arguments against it. Accidental variable collisions from refactoring would usually produce a type error or a partial function warning, and in any event I have never seen Erlang programmers complaining about this feature causing problems (and Haskell has far better compile-time tools for identifying its misuse). As far as the use of Eq goes, Eq is already enshrined in pattern matching by pattern matching against literals. And yes, with OverloadedStrings you can pattern match against anything with an IsString instance. If a type has a nonsensical Eq instance, I do not think that the programmer is any more likely to absentmindedly try `f x x = ` than the equivalent `f x y | x == y =`. Bad Eq instances have enough pitfalls already that I do not see much problem with adding another. Ian ________________________________________ From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on behalf of Daniel Trstenjak [daniel.trsten...@gmail.com] Sent: Tuesday, April 09, 2013 9:07 AM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Prolog-style patterns 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 _______________________________________________ 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
