!RE: Implicit reboxing of unboxed tuple in let-patterns

[Simon Peyton Jones]

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-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 02 September 2020 14:47
To: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
Cc: GHC developers <ghc-devs at haskell.org>
Subject: Re: Implicit reboxing of unboxed tuple in let-patterns




On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200907/968914e3/attachment.html>