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

[Eric Seidel]

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