> On the other hand, I think that the pat=expr syntax was something of a
> design error and it may not be supported in future releases. Judging from
> email that I've received, the similarity of == and = does cause confusion.
> In fact, it has also caught me on at least one occassion! (So yes
Kent Karlsson says:
>Parsing Haskell list comprehensions deterministically ((LA)LR) is currently very
>hard, since both "pat <- exp" (or also "pat gd <- exp", as suggested by Thomas)
>and "exp" are allowed as qualifiers in a list comprehension. Patterns and
>expressions can look
In response to some comments from Nikhil:
| Thomas says:
| >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
(I sent this before, but it didn't seem to get through. Sorry if
it's a repeat for anyone.)
-
More on (n+k) patterns. (I'm inflamed!) In response to JL's latest:
> The problem is only partly to do with naturals. Having these would
> certainly improve matters but I suspect the Nu
Thomas says:
>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:
>
>
>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
>[ |
