Are pattern guards obsolete?
Claus Reinke
claus.reinke at talk21.com
Wed Dec 13 21:40:05 EST 2006
>> does this clarify things?
>
> No. Pattern guards are "obvious", they could only work in one
> particular way, and they do work that way. They make common things
> easier, and increase abstraction. If your only argument against them
> requires category theory, then I'd say that's a pretty solid reason
> for them going in.
sigh.. slow down please, will you?
you addressed this reply to me. yet I have been careful, each time this
topic comes up, to argue neither in favour nor against pattern guards.
instead, my purpose has been to clarify misconceptions, eg., by
demonstrating how pattern guards, even though they do add substantial
convenience, do not add fundamentally new expressiveness (they can
be replaced by a local rewrite), or in this case by providing the examples
Iavor asked for, showing the difference in three uses of '<-' as generators
and booleans as guards.
I do not mind if pattern guards make it into Haskell, precisely because I
know how to sugar them away - once all implementations support them,
I might even use them more. Nevertheless, I wanted to support Yitzchak's
argument, namely that '<-' is used for generators in monadic contexts, but
its use in pattern guards is different from that in list comprehensions and do.
pattern guards are useful, once explained, but there is nothing particularly
obvious about them, nor is there only one way to formulate them: the usual
argument that they are just list comprehension syntax transferred to guards
breaks down because of the differences Yitzchak is concerned about, and
the correspondent claiming to be apfelmus has already shown that a direct
embedding of Maybes would be at least as natural as the current implicit
embedding into the effect-free part of an unknown monad.
> The argument that people seem to be making is that they are confusing,
> I completely disagree.
>
> f value | Just match <- lookup value list = g match
>
> Without thinking too hard, I am curious how anyone could get the
> meaning of this wrong if they understand the rest of Haskell. Can you
> show a concrete example, where you think a user would get confused?
sure, the one you gave right there. to be consistent with other uses of '<-'
as a generator, I'd expect to write either
f value | match <- lookup value list = g match
or
f value | Just match <- return (lookup value list) = g match
Claus
More information about the Haskell-prime
mailing list