> Currently, guarded patterns are not allowed i list comprensions.
> I see no reason for this restriction, so I propose that we
> allow them.
>
> For example, one cannot write
> [ .... | (a,b)|a==b <- blablabigexpression ]
> but one has to write
> [ .... | (a,b) <- blablabigexpression, a==b ]
>
>
> What is the advantage of this?
I find it more natural put the extra condition in conjunction
with the pattern. Here's a real world example, from the
LALR parser generator I'm currently writing:
[ .. | ..... (lsy, l, s:r) <- [all_kernel_item_tab ! kno], isNonterm s ]
The pattern (lsy, l, s:r) is *already* acting as a filter since s:r is
refutable, and isNonterm s is just one more condition. It seems rather
arbitrary that one bit of the filtering can be done in the pattern but
another, the boolean condition, can't. It would thus be more natural to say
[ .. | ..... (lsy, l, s:r)|isNonterm s <- [all_kernel_item_tab ! kno] ]
(which is actually what I did, which is how I discovered what I consider
as a bug in the syntax).
AN ASIDE: Actually, in this example, what I *really* wanted was a
definitional list comprension (Kevin, was that what you called it?
You wrote a note about this ages ago):
So that a qualifier can also be a let or where definition,
perhaps like:
[ .. | ..... (lsy, l, s:r)|isNonterm s = all_kernel_item_tab ! kno ]
The problem with this syntax is that = looks too much like ==.
-- Thomas
