
This is my feeling, too.
Alejandro
On 9 Mar 2021 at 09:14:12, Spiwack, Arnaud
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