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
Sent: 07 September 2020 20:46
To: Simon Peyton Jones
Cc: Richard Eisenberg ; Spiwack, Arnaud ; GHC developers
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 mailto: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 mailto:ghc-devs-bounces@haskell.org> On Behalf Of Richard Eisenberg
Sent: 02 September 2020 14:47
To: Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io>
Cc: GHC developers mailto:ghc-devs@haskell.org>
Subject: Re: Implicit reboxing of unboxed tuple in let-patterns
On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud mailto: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.orgmailto:ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devshttps://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
