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

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

On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <arnaud.spiwack@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs