Is there any hope that `OrPatters` become more broadly usable?

Learn
1

Freom the documentation on OrPatterns:

[…] they may not bind any variables or constraints. This prohibits code like

value :: Either a a -> a
value (Left x; Right x) = x -- binds a variable

I see that it would be problematic in a general case, e.g. the code is broken if I change Either a a to Either a b, and one would have to write a RHS that can deals with both a and b and returns one type.

But what about doing other useful stuff to limit the matching of the patters further, e.g. guards? Consider something like this:

value :: Either a b -> c
value (Left x | x < 0; Right y | foo y) = _ -- still binds variables

It obviously doesn’t parse because it suffers the same issue, i.e. the patterns are binding variables.

I wonder if a symbol other than | could be used to mean “don’t actually bind stuff”, then it could be desugared to the more cumbersome

value :: Either a b -> c
value (Left ((<0) -> True); Right (foo -> True)) = _ -- doesn't bind variables
2

Would it be possible to bind variables and constraints but only have them in scope within guards but not the RHS of the = in a definition or -> in a case?

It seems intuitively appealing but also potentially rather thorny when where clauses enter the picture.

3 
{-# LANGUAGE PatternSynonyms, LambdaCase, ViewPatterns #-}

pattern Eitheraa :: a -> Either a a
pattern Eitheraa x <- ((\case {Left x -> x; Right x -> x}) -> x)

value (Eitheraa x) = x

It seems to me as soon as you want something even mildly more involved than what OrPatterns allow today, the code would become unreadable. So wrap the logic in a PattSyn; give it a meaningful name. OrPatterns: you don’t need them.