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.diatc...@gmail.com> Sent: 07 September 2020 20:46 To: Simon Peyton Jones <simo...@microsoft.com> Cc: Richard Eisenberg <r...@richarde.dev>; Spiwack, Arnaud <arnaud.spiw...@tweag.io>; GHC developers <ghc-devs@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@haskell.org<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 <ghc-devs-boun...@haskell.org<mailto:ghc-devs-boun...@haskell.org>> On Behalf Of Richard Eisenberg Sent: 02 September 2020 14:47 To: Spiwack, Arnaud <arnaud.spiw...@tweag.io<mailto:arnaud.spiw...@tweag.io>> Cc: GHC developers <ghc-devs@haskell.org<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 <arnaud.spiw...@tweag.io<mailto:arnaud.spiw...@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<mailto:ghc-devs@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>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
