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@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@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@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@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