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

[Eric Seidel]

I'm inclined to agree that change (A) should be rejected, specifically that we should view this as a bug in the Manual rather than the implementation.

Change (B) seems quite reasonable though. We could suggest resubmitting it separately, or suggest revising the proposal to only propose (B). If we reject (A), it might also make sense to issue a warning for an unbanged unboxed tuple patterns, to make it abundantly clear that the pattern will be matched strictly. I used unboxed tuples for the first time last week, and to be honest the question of whether my unboxed tuple pattern would be matched strictly or lazily didn't even occur to me! I think I would have been very happy had GHC yelled at me about that.

On Wed, Aug 15, 2018, at 20:37, Vitaly Bragilevsky wrote:
> Hi,
> 
> the lazy unboxed tuples proposal  (
> https://github.com/ghc-proposals/ghc-proposals/pull/35) 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee