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

[Simon Peyton Jones]

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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Vitaly Bragilevsky
Sent: 16 August 2018 01:37
To: ghc-steering-committee at 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/35<https://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180816/2aa310b8/attachment.html>