[Haskell-cafe] Prolog-style patterns

Sturdy, Ian sturdyi12 at mail.wlu.edu
Tue Apr 9 15:46:43 CEST 2013


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-bounces at haskell.org [haskell-cafe-bounces at haskell.org] on behalf of Daniel Trstenjak [daniel.trstenjak at gmail.com]
Sent: Tuesday, April 09, 2013 9:07 AM
To: haskell-cafe at 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 at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe





More information about the Haskell-Cafe mailing list