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

[Richard Eisenberg]

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) <vlad.z.4096 at gmail.com> 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 <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
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee