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

[Iavor Diatchki]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200907/c03150b8/attachment.html>