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 <ghc-devs-boun...@haskell.org> *On Behalf Of *Richard > Eisenberg > *Sent:* 02 September 2020 14:47 > *To:* Spiwack, Arnaud <arnaud.spiw...@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.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 > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
