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

Thu Mar 11 12:51:15 UTC 2021

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 <trupill at gmail.com> wrote:
> 
> This is my feeling, too.
> 
> Alejandro
> 
> On 9 Mar 2021 at 09:14:12, Spiwack, Arnaud <arnaud.spiwack at tweag.io> 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 <rae at richarde.dev> 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 <mail at joachim-breitner.de> 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/0000-unboxed-sum-primops.md
>>> 
>>> 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 <mail at 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/367
>>>> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>>>> 
>>>> 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 at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> -- 
>> Joachim Breitner
>>  mail at joachim-breitner.de
>>  http://www.joachim-breitner.de/
>> 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee