Tommy Thorn writes:
> My only worry is that Haskell (if not already) is turning into the C++
> of functional languages, ie. feature upon feature. Haskell is already
> quite a mouthfull to learn.
This worries me too. Not least is the problem that <- is not a
particularly natural syntax for this feature, as others have noted.
(Though I admit the connection with qualifiers is tempting.)
Simon PJ writes:
> Re (b) we write
>
> f (x:xs) [] = e1
> f (x:xs) (y:ys) = e2
>
> when you might think we should find a syntax to allow
>
> f (x:xs) [] = e1
> (y:ys) = e2
>
> But we write out the common prefix and expect the compiler to spot the
> common pattern. Similarly I think we should rely on the compiler to spot
> common prefixes of guards.
>
> f x y | (x:xs) <- xs,
> [] <- ys
> = e1
>
> | (x:xs) <- xs,
> (y:ys) <- ys
> = e2
>
> The only extra difficulty is that the RHS of the pattern guard can be an
> expression.
I have to say, this looks pretty ugly to me, and I'm not sure I would
be happy trusting it to an optimiser.
It is arguably a mistake that Haskell does not allow some way of
capturing commonality in pattern matching. As I recall, we very
nearly added the syntax
f (x:xs) [] = e1
' ' (y:ys) = e2
and refrained only because we wanted a conservative design. Simon's
suggestion strikes me as far from conservative, so perhaps it is worth
revisiting more general issues of pattern matching.
-- P
