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

Thu Sep 10 09:16:30 UTC 2020

One thing that I had missed, until Simon pointed it out, is that in a let
pat = … expression, only the outermost pattern of pat is lazy. So

let (x,Just y) = (1, undefined) in x `seq` ()

Diverges. (whereas let (x,~(Just y)) = (1, undefined) in x `seq` ())
doesn’t).

So, really, we are only speaking of the outermost pattern, which does
simplify the discussion a little.

I don’t think that I share Iavor’s concern. In fact, I’ve got to say that I
personally don’t see (1) as meaning that the pattern is actually strict. I
just see a lazy pattern which happens to be immediately forced, because an
unlifted variable is bound. In this view, it doesn’t follow that the
presence of some unlifted pattern deep inside a lazy pattern ought to force
the pattern.

However, if the outermost pattern is unlifted, then it’s most likely that
it is not intended for the pattern to be lazy. From there, I see four ways
forward:

   1. Make let pat = … strict if the outermost pattern is unlifted
   2. Make let pat = … emit a warning if the outermost pattern is unlifted,
   but not explicitly banged.
   3. Decide that I’m mistaken, and that the current design is fine
   4. Decide that I’m mistaken, and that Iavor’s design it best

What do you think? I’ll try and make a proposal soon (unless (3) is too
popular for a proposal to be worth it).

On Tue, Sep 8, 2020 at 12:02 AM Simon Peyton Jones simonpj at microsoft.com
<http://mailto:simonpj@microsoft.com> wrote:

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> 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> *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>
> 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
> 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/20200910/0fe4ddc0/attachment.html>