The link to the pull request is incorrect in Joachim's email (though the link to the text of the proposal is perfectly fine). The appropriate link is https://github.com/ghc-proposals/ghc-proposals/pull/526 On Sat, Oct 8, 2022 at 12:06 PM Joachim Breitner wrote:

Dear Committee, Applicative comprehensions have been proposed by M Farkas-Dyck

https://github.com/ghc-proposals/ghc-proposals/pull/516

https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicativ...

I suggest Simon Marlow to shepherd this proposal.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

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

Hi, On 08/11/2022 12:49, Joachim Breitner wrote:

Dear Committee,

parallelism semaphores have been proposed by Douglas Wilson, Sam Derbyshire, Matthew Pickering

https://github.com/ghc-proposals/ghc-proposals/pull/540

https://github.com/sheaf/ghc-proposals/blob/jsem/proposals/0540-jsem.rst

I suggest Adam shepherds this proposal.

I'm not sure if we have explicit guidelines regarding conflicts of interest (should we?), but I think I should declare a conflict in this case. The authors of this proposal work for Well-Typed and have proposed and implemented this feature on behalf of a client, which might give the impression of potential bias. I am happy to take the advice of the committee on how to handle this situation. While I don't think I need to recuse myself from discussion of the proposal completely, it seems like it would be better for it to be shepherded by someone else? Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

On 09/11/2022 21:33, Joachim Breitner wrote:

Hi,

Am Mittwoch, dem 09.11.2022 um 21:04 +0000 schrieb Adam Gundry:

...

I'm not sure if we have explicit guidelines regarding conflicts of interest (should we?), but I think I should declare a conflict in this case. The authors of this proposal work for Well-Typed and have proposed and implemented this feature on behalf of a client, which might give the impression of potential bias.

I am happy to take the advice of the committee on how to handle this situation. While I don't think I need to recuse myself from discussion of the proposal completely, it seems like it would be better for it to be shepherded by someone else?

we tend to have multiple well-tyists or tweagers on the committee, and so far we mostly worked under the assumption that committee members manage to do their committee work unencumbered by their jobs. So unless you, say, personally tasked someone with writing that proposal, or genuinely (and not just formally) _feel_ conflicted, I’d say don’t worry. We are all just trying to make GHC better, not govern a country or something like that :)

I've talked this over with my colleagues, and I think I am sufficiently conflicted that I shouldn't shepherd the proposal. In particular, I've have had frequent discussions of the work with the authors and our client, so it would be difficult for me to make an objective recommendation for acceptance or rejection. More broadly, I do think in general it would be preferable for a shepherd not to be from the the same company as or a close collaborator of the proposal author(s). I accept that in a small community this may not always be desirable as a strict rule, not least because the shepherd is "merely" making a recommendation to the committee rather than formally deciding the fate of the proposal. But I think it is helpful where possible for a couple of reasons: (a) to avoid giving the impression that by having a representative on the committee, companies will have an easier time getting their proposals accepted; and (b) to improve the quality of proposals by having them carefully scrutinized by a shepherd with a different background from the authors. Sorry to be ducking out of this one. I'd be happy to swap shepherding duties with someone else if there are any proposals in a suitable state for that to make sense? Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

On Wed, Nov 16, 2022, at 14:19, Joachim Breitner wrote:

I suggest you swap with Eric on #529, which I just assigned earlier to day, so he likely didn’t get started already.

I literally just saw that email, so happy to swap.

Hi Committee, Douglas Wilson, Sam Derbyshire, and Matthew Pickering have proposed adding support for a job-server to GHC. The goal is to allow Cabal and Stack to make optimal use of system resources when compiling many packages. Currently, the build tools are forced to choose between 1. parallelizing across packages, but compiling each package single-threaded 2. parallelizing within packages, but compiling packages sequentially There is no correct choice for all build plans, so the authors propose a lightweight job-server protocol to allow Cabal and GHC to cooperatively decide on the best parallelization strategy. The implementation is already done and the changes to GHC are supposed to be quite self-contained. At a high level GHC's participation in the protocol is thus: 1. when invoked with -jsem /path/to/job-server, acquire N job tokens from the job server 2. call `setNumCapabilities N` 3. compile as usual 4. before exiting, return the tokens to the job server There are more details in how GHC chooses how many tokens to request, and more opportunities for optimization, e.g. returning early returning of unneeded tokens, but this is really the essence of the protocol from GHC's perspective. --- 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. https://github.com/ghc-proposals/ghc-proposals/pull/540 Eric On Wed, Nov 16, 2022, at 14:21, Joachim Breitner wrote:

Hi,

Am Dienstag, dem 08.11.2022 um 13:49 +0100 schrieb Joachim Breitner:

...

Dear Committee,

parallelism semaphores have been proposed by Douglas Wilson, Sam Derbyshire, Matthew Pickering

https://github.com/ghc-proposals/ghc-proposals/pull/540

https://github.com/sheaf/ghc-proposals/blob/jsem/proposals/0540-jsem.rst

I suggest Adam shepherds this proposal.

JFTR: I’m reassigning this to Eric (hope that’s ok for you).

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

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

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

On Tue, Feb 14, 2023, at 00:59, Arnaud Spiwack 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.

(I know you ultimately support this proposal, but I want to push back a bit on this argument.) I think it's a bit more nuanced than that. We are supposed to evaluate whether a proposed change will improve GHC compared to the alternatives (one of which is always "do nothing"). This is unavoidably a question of cost/benefit tradeoffs. One of the costs we must evaluate is implementation cost (others are maintenance cost, language complexity cost, etc). If the implementation is believed to be costly, in terms of time or blast radius, or similarly if nobody has signed up to do the work, we should absolutely discount the proposal compared to other, cheaper alternatives. We may still decide in favor of the more costly option if we believe the benefits outweigh the cost, but we cannot ignore cost as a factor. In this particular case, my reasoning is the following: * We have a proposed solution that might capture 80% of the value, but clearly not 100%. * The proposed solution has a very low implementation cost (the work is largely done), and appears to have a low maintenance cost (though that should be re-evaluated in the actual MR!). * There are ideas for alternate solutions that would likely get closer to capturing the full value, BUT * They lack a complete design, which means the cost is quite unclear, along many axes. * Nobody is offering to flesh out the design, much less commit to the implementation of the alternates. * Finally, as far as I can tell, nothing about the current 80% proposal precludes us from pursuing the 100% alternatives later on. As a result, I view this proposal as a low-cost, incremental improvement that does not conflict with the North Star solution. It would be even better if it moved us closer to the North Star, but my bar for low-cost changes is "non-conflicting".

Hi all, We have votes in favor from Joachim, Arnaud, Chris, Moritz, and Simon M, and silence otherwise. Simon PJ, Richard, Vlad, Adam: if you have thoughts or concerns about this proposal, please speak up! On Sun, Feb 12, 2023, at 12:01, Eric Seidel wrote:

Hi Committee,

Douglas Wilson, Sam Derbyshire, and Matthew Pickering have proposed adding support for a job-server to GHC.

The goal is to allow Cabal and Stack to make optimal use of system resources when compiling many packages. Currently, the build tools are forced to choose between

1. parallelizing across packages, but compiling each package single-threaded 2. parallelizing within packages, but compiling packages sequentially

There is no correct choice for all build plans, so the authors propose a lightweight job-server protocol to allow Cabal and GHC to cooperatively decide on the best parallelization strategy.

The implementation is already done and the changes to GHC are supposed to be quite self-contained. At a high level GHC's participation in the protocol is thus:

1. when invoked with -jsem /path/to/job-server, acquire N job tokens from the job server 2. call `setNumCapabilities N` 3. compile as usual 4. before exiting, return the tokens to the job server

There are more details in how GHC chooses how many tokens to request, and more opportunities for optimization, e.g. returning early returning of unneeded tokens, but this is really the essence of the protocol from GHC's perspective.

---

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.

https://github.com/ghc-proposals/ghc-proposals/pull/540

Eric

On Wed, Nov 16, 2022, at 14:21, Joachim Breitner wrote:

...

Hi,

Am Dienstag, dem 08.11.2022 um 13:49 +0100 schrieb Joachim Breitner:

...

Dear Committee,

parallelism semaphores have been proposed by Douglas Wilson, Sam Derbyshire, Matthew Pickering

https://github.com/ghc-proposals/ghc-proposals/pull/540

https://github.com/sheaf/ghc-proposals/blob/jsem/proposals/0540-jsem.rst

I suggest Adam shepherds this proposal.

JFTR: I’m reassigning this to Eric (hope that’s ok for you).

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

Hi, Am Mittwoch, dem 16.11.2022 um 09:54 +0100 schrieb Joachim Breitner:

Template Haskell quotes as patterns has been proposed by John Ericson

https://github.com/ghc-proposals/ghc-proposals/pull/529

https://github.com/Ericson2314/ghc-proposals/blob/th-quotes-as-patterns/prop...

I suggest Eric shepherds this proposal.

JFTR, as discussed in the thread on #540, Adam will shepherd this one, and I’m re-assigning #540 to Eric. Sorry for the back-and-forth! Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi, Am Freitag, dem 18.11.2022 um 09:20 +0100 schrieb Joachim Breitner:

Make Symbol a newtype over String has been proposed by Oleg Grenus

https://github.com/ghc-proposals/ghc-proposals/pull/546 https://github.com/phadej/ghc-proposals/blob/symbol-type/proposals/0000-symb...

I suggest Chris Dornan shepherds this proposal.

the authors has ran out of patience with our silence, and bureaucratic comments that parts of it should maybe a CLC proposal, nd has given up on this proposal: https://github.com/ghc-proposals/ghc-proposals/pull/546#issuecomment-1344604... Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

I have decided the simplest way to rescue the proposal is to resubmit it myself as #562 https://github.com/ghc-proposals/ghc-proposals/pull/562 Chris

On 9 Dec 2022, at 19:46, Chris Dornan wrote:

I am sorry, this is on me. I have also apologised to Oleg in the thread. I was trying to close out #270 so I could give it my full attention but just as it seems headed for resolution more complications emerge.

I have offered to try and make the process work for Oleg but failing that I will try and find a new sponsor as the proposal seemed to be worthy.

Chris

...

On 9 Dec 2022, at 19:01, Joachim Breitner wrote:

Hi,

Am Freitag, dem 18.11.2022 um 09:20 +0100 schrieb Joachim Breitner:

...

Make Symbol a newtype over String has been proposed by Oleg Grenus

https://github.com/ghc-proposals/ghc-proposals/pull/546 https://github.com/phadej/ghc-proposals/blob/symbol-type/proposals/0000-symb...

I suggest Chris Dornan shepherds this proposal.

the authors has ran out of patience with our silence, and bureaucratic comments that parts of it should maybe a CLC proposal, nd has given up on this proposal: https://github.com/ghc-proposals/ghc-proposals/pull/546#issuecomment-1344604...

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