Re: [ghc-steering-committee] Recommendation: reject #367 (was: Re: Please review #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow)

There's an interesting point here I'd like to highlight: Vlad is implicitly suggesting a new policy of allowing primop interfaces to change between releases without a migration plan. I don't have an informed opinion of whether this is a good idea, but it does seem plausible -- especially if there are also stable interfaces wrapping the primops. Enshrining this policy would allow us to accept this current #367 as well as, perhaps, other proposals in this space that would be otherwise hard to accept. Richard

On Mar 11, 2021, at 7:51 AM, Vladislav Zavialov (int-index) wrote:

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

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