pattern guards (was: Parallel list comprehensions)

Claus Reinke claus.reinke at
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 

    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..


[*] 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