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@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 *On Behalf Of *Richard Eisenberg *Sent:* 02 September 2020 14:47 *To:* Spiwack, Arnaud *Cc:* GHC developers *Subject:* Re: Implicit reboxing of unboxed tuple in let-patterns

On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud 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