pattern guards (was: Parallel list comprehensions)
Claus Reinke
claus.reinke at talk21.com
Thu Feb 16 08:14:32 EST 2006
> Oh golly. I can't live without pattern guards. they are the best darn
> thing since sliced bread. I highly recommend them. I .. would have
> to seriously refactor a ton of code if pattern guards disapeared.
>
> So much so that it would be less work to implement pattern guards for
> other compilers and submit the patches.
eh, well, pattern guards are nice. but, many of their uses are also
easily replaced, by moving the pg-monad from the lhs to the rhs,
and employing MonadPlus for the fall-throughs; something roughly
like:
f p1 | g1 = e1
..
f pn | gn = en
where <stuff>
-->
f x = fromJust $ do {p1 <- return x; guard g1; return e1}
..
`mplus` do {pn <- return x; guard gn; return en}
where <stuff>
for any pattern matches in the guards, just drop the "guard";-)
grouping several guards under one pattern is also straightforward.
the only problem is where to place any pattern-dependent wheres.
the easy approach matches them lazily out of x, but that matches
some things twice..
this is not an argument against pattern guards; but I often find to
my surprise that many Haskellers still think that functions with
several clauses can't be translated easily (without losing the
basic structure [*]) because of the "fall-through" on pattern-match
failure, so they might find this translation pattern useful;
it could also be elaborated (recovering better error messages)
into a naive, but readable, desugaring of pattern-guards and the
like, for reports, and for not-yet-supporting implementations..
cheers,
claus
[*] to be more accurate, since you can move the whole group
of clauses into a case, the barrier is seen between moving
from the world of patterns and guards to the world of
expressions. MonadPlus allows us to move back.
More information about the Haskell-prime
mailing list