Implicit reboxing of unboxed tuple in let-patterns

[Iavor Diatchki]

Yeah, I think these are nice examples that illustrate some of the
problems with the current behavior of GHC.   For example, I think it is
weird that `b` non-terminates, but `c` does, because `z` is not used.  I
would expect those to be equivalent.

My preference would be to use the simple rule I mentioned before, but
change how bang patterns work in pattern bindings.  In particular, I think
writing a bang pattern should constitute a use of the banged value.  I
think two equivalent ways to specify this is to say that a) writing a
nested bang pattern implicitly adds bangs to the enclosing patterns, or I
think equivalently b) writing `!p` is the same as writing `x at p` and adding
`seq x` the same way we do for simple `!x = e` definitions

With this interpretation, all but `e` would diverge, which matches my
intuition of how unboxed types should work.

-Iavor


On Thu, Sep 3, 2020 at 11:02 AM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Sep 3, 2020, at 1:51 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> How about the following rule:  unlifted patterns are always strict (i.e.,
> you desugar them as if they had an explicit  `!`).   A pattern is
> "unlifted" if the type it examines is unlifted.   Seems simple enough and,
> I think, it would do what most folks would expect.
>
>
> I don't think it's this simple. For example:
>
> > data X = MkX Int#
> >
> > a = let MkX 3# = undefined in ()
> > b = let MkX z = undefined in ()
> > c = let MkX _ = undefined in ()
> > d = let MkX {} = undefined in ()
> > e = let _ :: X = undefined in ()
>
> Which of these diverge? e definitely converges, as X is lifted. b
> definitely diverges, because it binds z, a variable of an unlifted type, to
> a component of a diverging computation.
>
> In GHC today, all the cases other than b converge.
>
> Iavor suggests that a should diverge: 3# is a pattern of an unlifted type.
> What about c? What about d? Very unclear to me.
>
> Note that banging the pattern nested inside the MkX does not change the
> behavior (in GHC today) for any of the cases where this makes sense to do
> so.
>
> Richard
>
>
> I guess a more explicit option would be to make it an error to use a lazy
> pattern on an unlifted type, and require programmers to manually add the
> `!` but I am not sure that gains much, and is more work in the compiler.
>
> -Iavor
>
> On Thu, Sep 3, 2020 at 10:38 AM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>>
>>
>> On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> This is all a tad tricky, I must say.
>>
>>
>> ... which is one of the reasons I originally wanted one simple rule. I'm
>> not now saying I was in the right, but it is an attractive resting point
>> for this discussion.
>>
>> To be clear, I don't think there's going to be any concrete action here
>> without a proposal, so perhaps once this thread finds a resting point
>> different than the status quo, someone will have to write it up.
>>
>> Richard
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200903/d68295b3/attachment.html>