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

Alejandro Serrano Mena trupill at gmail.com
Tue Mar 9 15:38:37 UTC 2021


 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/47bef01b/attachment-0001.html>


More information about the ghc-steering-committee mailing list