There is no fundamental problem with non-linear patterns using ==. (The functional logic programming world long ago generalised the idea of unification to 'narrowing'.) There _is_ a technical problem in Haskell about whether the == here is necessarily the one from the Prelude or whether it might be a different == that is in scope: what would import Prelude hiding (Eq) x == y = x < y member x (x:_ ) = True member x (_:ys) = member x ys member _ [] = False mean? What, if anything, would it mean when no == is in scope? This is something that could be sorted out with good will. For example, you could say that it is a compile-time error if this notation is used and Prelude.== is not in scope. But since guards make the linear pattern restriction less poctalgic than it is in say ML, people have found other maddened grizzly bears to stun first. We had similar questions about n+k patterns, a feature that I still love.