[ghc-steering-committee] #540: parallelism semaphores, recommendation: *accept*

[Chris Dornan]

I 100% agree with what Arnaud is saying in general. I think it is just that this particular proposal is so non-disruptive, that engineering issues dominate, and we don't feel it would be productive to have one of our regular exhaustive discussions of the options as it would risk stalling an important initiative to very little good purpose (in this case).

Normally, where the potential fir disruption to the wider Haskell ecosystem is great, whether a proposal has an implementation behind should not be a  consideration (in my view, at least).



> On 14 Feb 2023, at 07:59, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> I would like to oppose the argument that “it's already implemented” is a strong argument for this court. It certainly helps evaluate feasibility, but we are supposed to evaluate whether something is a good idea.
> 
> That being said, considering that
> 1/ better solutions are hard to design (and even hard to prove better, as there is not really a standard job server outside of Macos)
> 2/ it is believed that almost no user will have to use this command themselves (we expect `-jsem` to be called in a handful of places, such as in the Cabal tool and possibly in the Stack tool)
> 
> I think the benefit will largely outweigh the costs, and am in favour.
> 
> On Mon, 13 Feb 2023 at 17:24, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> I have wanted this for many years.
>> 
>> I have one question which I put in the thread but it really should not get in the way of making things better -- let's iterate.
>> 
>> +1 from me.
>> 
>> Chris
>> 
>>> On 13 Feb 2023, at 01:45, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>> 
>>> > On balance, I think we should accept this proposal and not let the perfect be the enemy of the good.
>>> 
>>> I agree with this. An incremental improvement is an improvement. And if need/interest/funding is there can be iterated upon.
>>> 
>>> On Mon, 13 Feb 2023 at 5:11 AM, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>>>> Hi,
>>>> 
>>>> Am Sonntag, dem 12.02.2023 um 14:01 -0500 schrieb Eric Seidel:
>>>> > I have two minds about this proposal. On the one hand, it seems
>>>> > likely to leave performance on the table compared to the alternatives
>>>> > discussed. But on the other hand, this proposal has already been
>>>> > implemented and validated by Well-Typed, and it seems like a small
>>>> > amount of additional complexity for GHC to adapt. (Though I'd love
>>>> > for someone with more knowledge of GHC internals to opine on the
>>>> > internal complexity.)
>>>> > 
>>>> > On balance, I think we should accept this proposal and not let the
>>>> > perfect be the enemy of the good.
>>>> 
>>>> I agree. Especially given that there is an implementation, I see no
>>>> good reason why we shouldn’t trust the implementors and authors’s good
>>>> sense in their design choices.
>>>> 
>>>> Cheers,
>>>> Joachim
>>>> -- 
>>>> Joachim Breitner
>>>>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>>>   http://www.joachim-breitner.de/
>>>> 
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org <mailto: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 <mailto: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 <mailto: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/20230214/8fa7c256/attachment.html>