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 <ghc-devs-boun...@haskell.org> On Behalf Of Richard Eisenberg Sent: 02 September 2020 14:47 To: Spiwack, Arnaud <arnaud.spiw...@tweag.io> Cc: GHC developers <ghc-devs@haskell.org> Subject: Re: Implicit reboxing of unboxed tuple in let-patterns On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <arnaud.spiw...@tweag.io<mailto:arnaud.spiw...@tweag.io>> wrote: Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know what the semantics of these ought to be. It does look like an interesting can of worms. How do they currently desugar? Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the pattern is an unlifter-var pattern and is strict. The pattern must be banged, unless the bound variable is not nested. This rule is consistent across all features. This thread is suggesting to add a special case -- one that seems to match intuition, but it's still a special case. And my question is: should the special case be for unboxed tuples? or should the special case be for any pattern whose overall type is unlifted? Richard
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
