One thing that I had missed, until Simon pointed it out, is that in a let pat = … expression, only the outermost pattern of pat is lazy. So
let (x,Just y) = (1, undefined) in x `seq` () Diverges. (whereas let (x,~(Just y)) = (1, undefined) in x `seq` ()) doesn’t). So, really, we are only speaking of the outermost pattern, which does simplify the discussion a little. I don’t think that I share Iavor’s concern. In fact, I’ve got to say that I personally don’t see (1) as meaning that the pattern is actually strict. I just see a lazy pattern which happens to be immediately forced, because an unlifted variable is bound. In this view, it doesn’t follow that the presence of some unlifted pattern deep inside a lazy pattern ought to force the pattern. However, if the outermost pattern is unlifted, then it’s most likely that it is not intended for the pattern to be lazy. From there, I see four ways forward: 1. Make let pat = … strict if the outermost pattern is unlifted 2. Make let pat = … emit a warning if the outermost pattern is unlifted, but not explicitly banged. 3. Decide that I’m mistaken, and that the current design is fine 4. Decide that I’m mistaken, and that Iavor’s design it best What do you think? I’ll try and make a proposal soon (unless (3) is too popular for a proposal to be worth it). On Tue, Sep 8, 2020 at 12:02 AM Simon Peyton Jones simo...@microsoft.com <http://mailto:simo...@microsoft.com> wrote: 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> 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 > <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
