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

[Simon Peyton Jones]

I think this is the consistent way to interpret your rule (1) that unlifted bindings are always strict

But that’s not what rule (1) says.  It says that a pattern binding is strict iff it binds a variable of unlifted type.

Now I think we agree that your proposal says that a pattern binding is strict iff it or any of its sub-patterns has unlifted type, including wild-cards, variables, and constructor patterns; in fact any sub-pattern.   Call that (2).

So

  *   (1) is necessary.
  *   (2) is strictly stronger, and will make fewer program defined.  But is perhaps less surprising.

I think you could make a proposal out of that if you wanted.  I can’t decide if I like it, myself, but I think that it, too, is simple and consistent.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 07 September 2020 20:46
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Richard Eisenberg <rae at richarde.dev>; Spiwack, Arnaud <arnaud.spiwack at tweag.io>; GHC developers <ghc-devs at haskell.org>
Subject: Re: !RE: Implicit reboxing of unboxed tuple in let-patterns



On Mon, Sep 7, 2020 at 5:12 AM Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:



  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”? I think this is fully compatible with unlifted user defined data
Just (# a,b #) = e
would be strict.   And even
MkT _ = e
would be strict if   data T = MkT (# Int,Int #)


Yes, the first one would be strict up to the tuple, and the second one would also be strict.  I think this is the consistent way to interpret your rule (1) that unlifted bindings are always strict, and it shouldn't really matter if you used a variable pattern, or a wild card pattern.  I don't think there's any other part of the language where replacing a `_` with an unused name changes the semantics of the program, and I don't think it should in this case either.

Just to be fully explicit, the thing I find odd with GHC's current behavior is that these two are different:

let MkT x = undefined in ()       --> undefined
let MkT _ = undefined in ()       --> ()

Even more explicitly:
let (_ :: Int#) = undefined in ()   --> ()    -- the value `undefined` is not representable in type `Int#` but GHC is happy to proceed because it doesn't need to represent it
let (x :: Int#) = undefined in ()    --> ()   -- same situation, but now GHC is strict, even though it still doesn't need to represent the value.

I think that the consistent behavior is for all of these to diverge, because laziness does not mix with unlfited values, at least in the presence of non-termination.

-Iavor










From: ghc-devs <ghc-devs-bounces at haskell.org<mailto: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<mailto:arnaud.spiwack at tweag.io>>
Cc: GHC developers <ghc-devs at haskell.org<mailto: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
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b8984af610438e315a08d853669e2b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351047493622347&sdata=mlcv1AZBJ%2FHQYDQtS7NPQ5YnbhQA17tWx9fzoVe8Gic%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200907/2a3c7163/attachment.html>