<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">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).<div><br></div><div>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).</div><div><br></div><div><br><div><br><blockquote type="cite"><div>On 14 Feb 2023, at 07:59, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div>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.</div><div><br></div><div>That being said, considering that</div><div>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)</div><div>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)</div><div><br></div><div>I think the benefit will largely outweigh the costs, and am in favour.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Feb 2023 at 17:24, Chris Dornan <<a href="mailto:chris@chrisdornan.com">chris@chrisdornan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I have wanted this for many years.<div><br></div><div>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.</div><div><br></div><div><span style="">+1 from me.</span></div><div><font><span><br></span></font></div><div><font><span>Chris<br></span></font><div><br><blockquote type="cite"><div>On 13 Feb 2023, at 01:45, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@gmail.com</a>> wrote:</div><br><div><div><div dir="auto">> <span style="word-spacing:1px;color:rgb(49,49,49)">On balance, I think we should accept this proposal and not let the perfect be the enemy of the good.</span></div><div dir="auto"><span style="word-spacing:1px;color:rgb(49,49,49)"><br></span></div></div><div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto">I agree with this. An incremental improvement is an improvement. And if need/interest/funding is there can be iterated upon.</div></div><div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto"><br></div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto"><span>On Mon, 13 Feb 2023 at 5:11 AM, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:</span><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Am Sonntag, dem 12.02.2023 um 14:01 -0500 schrieb Eric Seidel:<br>
> I have two minds about this proposal. On the one hand, it seems<br>
> likely to leave performance on the table compared to the alternatives<br>
> discussed. But on the other hand, this proposal has already been<br>
> implemented and validated by Well-Typed, and it seems like a small<br>
> amount of additional complexity for GHC to adapt. (Though I'd love<br>
> for someone with more knowledge of GHC internals to opine on the<br>
> internal complexity.)<br>
> <br>
> On balance, I think we should accept this proposal and not let the<br>
> perfect be the enemy of the good.<br>
<br>
I agree. Especially given that there is an implementation, I see no<br>
good reason why we shouldn’t trust the implementors and authors’s good<br>
sense in their design choices.<br>
<br>
Cheers,<br>
Joachim<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div>
</div>
_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
</div></blockquote></div><br></div></body></html>