Hi, your points sounds reasonable, and the author got a heads up on the Github thread (so unlikely that there was a misunderstanding or oversight), so I’ll concur with the shepherd. Cheers, Joachim Am Montag, den 08.03.2021, 15:51 +0000 schrieb Simon Marlow:

Committee,

Proposal #367 suggests using unboxed sums for the results of 7 (seven) primops that use sum types but currently have to encode those explicitly using `Int#`.

https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/...

The proposal is arguably the right thing, however I'm suggesting we reject it for the following reasons: The implementations of the primops would bake in the translation of unboxed sums. Right now our unboxed sum translation is defined in one place - CorePrep - but this proposal would leak it into the implementations of a few primops. Migration would entail adding a backwards-compatibility layer, with the associated complexity and risk of performance regressions. While the current situation is perhaps inelegant, it's not broken and it's easy to understand. Thoughts?

Simon

On Sun, 4 Oct 2020 at 22:14, Joachim Breitner wrote:

...

Dear Committee,

this is your secretary speaking:

Clarify primops using unboxed sum has been proposed by David Feuer https://github.com/ghc-proposals/ghc-proposals/pull/367 https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/...

I’ll propose Simon Marlow as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks, Joachim _______________________________________________ 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/

I don't have an informed opinion. I'll trust Simon. It may very well be a case of “it would have been the right thing to do were we to start from scratch today, but it is now too late to do so”. On Tue, Mar 9, 2021 at 4:25 AM Richard Eisenberg wrote:

I want to accept this. But, in the end, I don't see enough benefit (which seems to be mostly aesthetic) to justify the (somewhat modest, as these things go) costs.

I sadly agree with the shepherd to reject.

Richard

On Mar 8, 2021, at 11:59 AM, Joachim Breitner wrote:

Hi,

your points sounds reasonable, and the author got a heads up on the Github thread (so unlikely that there was a misunderstanding or oversight), so I’ll concur with the shepherd.

Cheers, Joachim

Am Montag, den 08.03.2021, 15:51 +0000 schrieb Simon Marlow:

Committee,

Proposal #367 suggests using unboxed sums for the results of 7 (seven) primops that use sum types but currently have to encode those explicitly using `Int#`.

https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/...

The proposal is arguably the right thing, however I'm suggesting we reject it for the following reasons: The implementations of the primops would bake in the translation of unboxed sums. Right now our unboxed sum translation is defined in one place - CorePrep - but this proposal would leak it into the implementations of a few primops. Migration would entail adding a backwards-compatibility layer, with the associated complexity and risk of performance regressions. While the current situation is perhaps inelegant, it's not broken and it's easy to understand. Thoughts?

Simon

On Sun, 4 Oct 2020 at 22:14, Joachim Breitner wrote:

Dear Committee,

this is your secretary speaking:

Clarify primops using unboxed sum has been proposed by David Feuer https://github.com/ghc-proposals/ghc-proposals/pull/367

https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/...

I’ll propose Simon Marlow as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks, Joachim _______________________________________________ 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/

_______________________________________________ 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

The complexity of the proposed migration strategy (with a transient compatibility layer) does not seem justified. I’m not sure if we should be worried about breaking changes to primops at all – they are more of an implementation detail than a user-facing API. We are supposed to export user-facing wrappers separately, and be able to change primops at will. Consider the tryTakeMVar# primop. Hackage Search reveals that it is used only by a handful of packages: base, ghc-prim, ghc, ghc-lib, ghc-lib-parser, concurrent-st, exctcore, haskell-names, haste-compiler, lhc, prim, primal, primitive, primitive-unlifted. The first three are under our control and can be updated immediately (base, ghc-prim, ghc). The following two are by their own nature compatibility layers (ghc-lib, ghc-lib-parser). And I’m sure the remaining 9 will be able to adapt without a complicated migration (we could even ask the implementor to submit patches to these projects, 9 is not a large amount). So I would recommend to ask the author to remove the migration plan and then I’d vote +0.5 on the proposal. As to the proposal in its current form, I concur with the recommendation to reject. - Vlad

On 9 Mar 2021, at 18:38, Alejandro Serrano Mena wrote:

This is my feeling, too.

Alejandro

On 9 Mar 2021 at 09:14:12, Spiwack, Arnaud wrote: I don't have an informed opinion. I'll trust Simon. It may very well be a case of “it would have been the right thing to do were we to start from scratch today, but it is now too late to do so”.

On Tue, Mar 9, 2021 at 4:25 AM Richard Eisenberg wrote: I want to accept this. But, in the end, I don't see enough benefit (which seems to be mostly aesthetic) to justify the (somewhat modest, as these things go) costs.

I sadly agree with the shepherd to reject.

Richard

...

On Mar 8, 2021, at 11:59 AM, Joachim Breitner wrote:

Hi,

your points sounds reasonable, and the author got a heads up on the Github thread (so unlikely that there was a misunderstanding or oversight), so I’ll concur with the shepherd.

Cheers, Joachim

Am Montag, den 08.03.2021, 15:51 +0000 schrieb Simon Marlow:

...

Committee,

Proposal #367 suggests using unboxed sums for the results of 7 (seven) primops that use sum types but currently have to encode those explicitly using `Int#`.

https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/...

The proposal is arguably the right thing, however I'm suggesting we reject it for the following reasons: The implementations of the primops would bake in the translation of unboxed sums. Right now our unboxed sum translation is defined in one place - CorePrep - but this proposal would leak it into the implementations of a few primops. Migration would entail adding a backwards-compatibility layer, with the associated complexity and risk of performance regressions. While the current situation is perhaps inelegant, it's not broken and it's easy to understand. Thoughts?

Simon

On Sun, 4 Oct 2020 at 22:14, Joachim Breitner wrote:

...

Dear Committee,

this is your secretary speaking:

Clarify primops using unboxed sum has been proposed by David Feuer https://github.com/ghc-proposals/ghc-proposals/pull/367 https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/...

I’ll propose Simon Marlow as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks, Joachim _______________________________________________ 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/

_______________________________________________ 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 _______________________________________________ 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

I'm content to follow Simon's recommendation. The proposal says I propose to replace the primops that produce product-encoded sums with ones that produce proper unboxed sums. And it is nicer to have primops that are more explicit about their types, but of course GHC's ultimate representation of an unboxed sum is precisely the same as the current primop's one. So this is purely an ergonomic improvement, and one that will be felt only by a small constituency. So the costs of the current setup are not heavy. It's a good proposal to have on file, in case it becomes more pressing some day. Simon From: ghc-steering-committee On Behalf Of Simon Marlow Sent: 08 March 2021 15:52 To: Joachim Breitner Cc: ghc-steering-committee@haskell.org Subject: [ghc-steering-committee] Recommendation: reject #367 (was: Re: Please review #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow) Committee, Proposal #367 suggests using unboxed sums for the results of 7 (seven) primops that use sum types but currently have to encode those explicitly using `Int#`. https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftreeowl%2Fghc-proposals%2Fblob%2Funboxed-sum-primops%2Fproposals%2F0000-unboxed-sum-primops.md&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673797668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Nm7owDB1Mxxt5MG2JGe1%2Fw9t7FpDxBhU%2BppV09grIgg%3D&reserved=0 The proposal is arguably the right thing, however I'm suggesting we reject it for the following reasons: 1. The implementations of the primops would bake in the translation of unboxed sums. Right now our unboxed sum translation is defined in one place - CorePrep - but this proposal would leak it into the implementations of a few primops. 2. Migration would entail adding a backwards-compatibility layer, with the associated complexity and risk of performance regressions. 3. While the current situation is perhaps inelegant, it's not broken and it's easy to understand. Thoughts? Simon On Sun, 4 Oct 2020 at 22:14, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee, this is your secretary speaking: Clarify primops using unboxed sum has been proposed by David Feuer https://github.com/ghc-proposals/ghc-proposals/pull/367https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F367&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673807671%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=VR%2F9%2BRcLdFCqGcmxuCqPseHbr2rTjBDcX6r6NwDDvBs%3D&reserved=0 https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftreeowl%2Fghc-proposals%2Fblob%2Funboxed-sum-primops%2Fproposals%2F0000-unboxed-sum-primops.md&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673807671%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=DRJrOd7m2X0sB1d9HdcdyHYUm7Z6HTuT0QHRB56FXFs%3D&reserved=0 I'll propose Simon Marlow as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-processhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673817669%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=D%2FI8%2BJNnqo8XTVWtptXntxmBRwYP2wxZVX8tNxlZCQA%3D&reserved=0 Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673827660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=lHwIB62LfzP%2F6e0MoitU5jlOQivnuB%2FrBlCgE7NOhfk%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673837651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=oRJy6pL6bv9ZN6Q28ybaOHHMJE4yb9ieW0goPBHU4iw%3D&reserved=0