[ghc-steering-committee] Proposal: Lazy unboxed tuples / warn on unbanged strict patterns (#35); Recommendation: Reject

[Vitaly Bragilevsky]

Hi Joachim,

I am not sure how to proceed here. I think we need sort of "so be it"
recommendation for such cases that are
* no big deal
* already implemented
* there is no strong opposition (as it looks like)

Maybe the easiest solution is to close corresponding pull request silently,
since the current implementation is not a committee process artifact anyway.


Vitaly




On Fri, Aug 17, 2018 at 9:56 AM Eric Seidel <eric at seidel.io> wrote:

> On Fri, Aug 17, 2018, at 12:10, Richard Eisenberg wrote:
> > I worry that everyone has missed the final sentence of the proposal:
> >
> > > This is already implemented, but it is easy enough to tweak the design.
> >
> > This proposal is fully implemented in 8.4, and I believe it is, too, in
> > 8.2. At the time the proposal was written, the new features had not been
> > released, and it was hoped that the discussion would influence the
> > design. But due to the fact that this was parked for so long, the
> > implementation has since been released.
>
> Oh? I understood "already implemented" to mean on a branch somewhere
> waiting to be merged.
>
> > The big motivation for (A) is that it removes unboxed tuples (resp.
> > sums) from being a special case. Now, we're uniform.
>
> Uniformity is a valuable principle. Another valuable principle is the
> Principle of Least Surprise, which I fear (A) runs afoul of, especially
> given the public discussion. That's my primary concern wrt. (A). The Manual
> states that the purpose of unboxed tuples is to return multiple values in
> registers or on the stack. Boxing the tuples for a lazy pattern match
> violates this purpose.
>
> Here's another alternative: keep the uniform behavior that is now
> implemented, and add a warning for lazy matches on unboxed tuples. I think
> I'd be happy with this warning. Yes, it adds a bit of syntactic overhead,
> but it also forces the programmer to clarify what's clearly a subtle issue!
>
> On the other hand, perhaps the fact that the change is actually in 8.4 and
> GHC is (presumably) not getting tickets about unexpectedly boxing
> unboxed-tuples means that this fuss is much ado about nothing, and GHC is
> clever enough to avoid the boxing.
>
> > The big motivation for (B) is that it allows more (correct) programs to
> > compile. The previous behavior was throwing out programs because GHC was
> > worried that the author was being silly -- but that's precisely what
> > warnings are good for.
>
> Indeed, and I fully support (B) regardless of the outcome for (A).
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180820/cbf74ac6/attachment.html>