I’m a bit late to this debate, but here are a few thoughts.
1. “Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the binding is strict.” Not only is this rule simple and consistent, it is also necessary: we cannot bind a variable of unlifted type to a thunk. So any new rule must include this, and maybe add something extra, complicating the language.
1. All lazy pattern bindings go via an intermediate tuple. If you write
(Just x, [y]) = e
then you get
t = case e of (Just x, [y]) -> (x,y)
x = fst t
y = snd t
The pattern can be complex and we don’t want to unpack it many times. Moreover, the semantics says that it must be fully matched, so even if you just want ‘x’, you must check that the second component of the pair is indeed a singleton list.
So the “going via a tuple” part is nothing special about unboxed tuples – it simply holds for all lazy pattern bindings.
1. I don’t understand the details of Iavor’s proposal to add that “unlifted patterns are strict”, in addition to (1). Do you mean “any sub-pattern of the LHS has an unlifted type”? So
Just (# a,b #) = e
would be strict. And even
MkT _ = e
would be strict if data T = MkT (# Int,Int #)
1. Anything we do *must* scale to when we have user-defined unlifted data types (a current GHC Proposal)
TL;DR. At the moment a change does not look attractive to me. I could live with a warning for *outermost* unboxed tuples (or in general a constructor of an unlifted data type), suggesting to add a “!” or a “~” to make the intent clear.
Simon
From: ghc-devs