I think the reason is more that it's a change that doesn't seem to be well-motivated, i.e. neither the proposal nor the discussion offer a compelling example where you would want an unboxed tuple to be matched lazily. That being said, I overlooked the implicit-bang alternative when I first read the proposal. That seems quite reasonable. The default behavior remains what people seem to expect, but enables the explicit use of lazy patterns should you want them. On Thu, Aug 16, 2018, at 03:38, Simon Peyton Jones via ghc-steering-committee wrote:

I’m actually mildly in favour of the proposed design.

The main reason for rejection is really

* It’s a change

Change is always a bit disruptive; and no one is arguing strongly that they really really want this.

So maybe we should just “park” it as OK in principle, but without sufficient support to justify the (hard to quantify) changeover costs.

Simon

From: ghc-steering-committee On Behalf Of Vitaly Bragilevsky Sent: 16 August 2018 01:37 To: ghc-steering-committee@haskell.org Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn on unbanged strict patterns (#35); Recommendation: Reject

Hi,

the lazy unboxed tuples proposal (https://github.com/ghc-proposals/ghc-proposals/pull/35https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F35&data=02%7C01%7Csimonpj%40microsoft.com%7C983115e9eee64eb4b03c08d603107655%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636699766583676606&sdata=PXTsCrM4otm8ZCEFZvNfkydSBo6J77zh5qb9CVNmZX8%3D&reserved=0) was under discussion for a long period of time (more than a year and a half since submission).

As a shepherd to this proposal I recommend rejection based on the following:

* there is no clearly articulated motivation in favor of this proposal despite complying with the Manual; * implementing this would lead to hard-to-trace performance issues in the users code (due to move from strictness in current GHC behaviour to laziness); * it looks like the change (B) of the proposal (warn an unbanged strict patterns) meets no complains, so it is better to be resubmitted as a separate proposal; * if resubmitted separately the change (A) should elaborate on desugaring to make potential performance drawbacks clear; * it seems (maybe mistakenly) that the author has lost his interest in this proposal.

Although silence is undestood as agreement, I'd be glad to receive a feedback on this recommendation.

Regards, Vitaly _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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).

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 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/