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

[Joachim Breitner]

Hi,

if your recommendation is “so be it”, then make that your official
recommendation. If there is no opposition within a week or so, we can
mark the proposal as accepted, and thus bless the status quo.

Cheers,
Joachim

Am Montag, den 20.08.2018, 10:05 -0700 schrieb 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
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180820/1d1c3b3e/attachment.sig>