Implicit reboxing of unboxed tuple in let-patterns

Spiwack, Arnaud arnaud.spiwack at tweag.io
Wed Sep 2 13:39:52 UTC 2020


> I admit I don't feel as strongly any more. My argument in that thread was
> from the standpoint of a language designer: there is really no reason, a
> priori, for an unboxed-tuple binding to be strict. What controls strictness
> is whether the bound variables are of unlifted type. However, I'm currently
> in more sympathy with language users, who (for whatever reason) seem to
> think that bindings with #s in them should be strict. (I have this
> intuition myself, even though it's not quite warranted on technical
> grounds.)
>

A middle ground could be to not allow unbanged patterns for unboxed tuples.
Since they currently exist, we could also simply emit a warning, saying:
“this is probably not what you want, do add an exclamation mark”.


> What do we think of
>
> pattern Unl x y = (# x, y #)
>
> ex1, ex2 :: ()
> ex1 = let Unl x y = Unl undefined undefined in ()
> ex2 = let Unl x y = undefined in ()
>
>
> ? Today, both ex1 and ex2 evaluate to (). If we were to change the
> specification here, would we consider any unlifted-type pattern (where the
> type of the pattern itself is unlifted, independent of the type of any of
> its bound variables) to be banged? Or would it be a super-special case for
> unboxed tuples?
>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200902/90829d28/attachment.html>


More information about the ghc-devs mailing list