September 2023 - ghc-steering-committee

Please review #569: multiline string literals, Shepherd: Eric
by Joachim Breitner 01 Jan '24

01 Jan '24

Dear Committee, Brandon Chinn has a proposal for multiline string literals. Let the bikeshedding begin. https://github.com/ghc-proposals/ghc-proposals/pull/569 https://github.com/brandonchinn178/ghc-proposals/blob/multiline-strings/pro… I’d like to nominate Eric as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 6

Stability
by Simon Peyton Jones 13 Oct '23

13 Oct '23

Dear GHC SC To avoid derailing the debate about -Wsevere <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/00…>, and HasField redesign <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/00…>, I'm starting a new (email for now) thread about stability. I have tried to articulate what I believe is an evolving consensus in this document <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47Zulg…> . If we converge, we'll turn that into a proper PR for the GHC proposal process, although it has wider implications than just GHC proposals and we should share with a broader audience. But let's start with the steering committee. Any views? You all have edit rights. I think that the draft covers Moritz's and Julian's goals, at least that was my intention. I have pasted Moritz's last email below, for context. Simon ========= Moritz's last email ============ Now, this is derailing the original discussion a bit, and I'm not sure how far we want to take this. But, regarding @Simon Marlow <marlowsd(a)gmail.com>'s comment This is one cultural aspect of our community I'd like to shift: the > expectation that it's OK to make breaking changes as long as you warn about > them or go through a migration cycle. It just isn't! (and I speak as > someone who used to make lots of changes, I'm now fully repentant!). That's > not to say that we shouldn't ever change anything, but when considering the > cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it > just defers it. I actually read this as we should stop having breaking changes to begin with. And _if_ we do have breaking changes, that deprecation does not change the need to actually change code (cost). As outlined in my reply to that, and @Richard Eisenberg <lists(a)richarde.dev>'s observation, it "smears" the cost. The--to me--_much_ bigger implication of deprecation cycles is that we _inform_ our _customers_ about upcoming changes _early_, instead of _after the fact_. We also give them ample time to react. Being by changing their code, or raising their concerns. Would the Simplified Subsumptions / Deep Subsumptions change have looked differently? As such I see deprecation cycles as orthogonal to the question if we should have breaking changes to begin with. Thus I believe the following: > - Do have a deprecation cycle if possible. > - Do not treat a deprecation cycle as an excuse. Costs are deferred but > are as large as ever. should be upgraded to: - Preferably _no_ breaking changes. - If breaking changes, then with a deprecation cycle, unless technically infeasible. - An understanding that any breaking change incurs significant costs. Ocaml recently added multicore support, and they put tremendous effort into making sure it keeps backwards compatibility: https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md PS: we should also agree that a "stable" extension should not require > dependencies on ghc-experimental. To become stable, any library support > for an extension must move into `base`. This seems like a good idea, however I still remain that _experimental_ features should not be on-by-default in a stable compiler. Yes, ideally I'd not even see them in a stable compiler, but I know this view is contentious. The use of `ghc-experimental` should therefore be guarded by `--std=experimental` as Julian suggested. That is a loud opt-in to experimental features.

7 32

#583: HasField redesign, rec: accept
by Arnaud Spiwack 12 Oct '23

12 Oct '23

Dear all, [ Proposal #583 https://github.com/ghc-proposals/ghc-proposals/pull/583 ] Our own Adam proposes to amend the design of the highly experimental OverloadedRecordUpdate extension as had been designed in proposal #158 [ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-r… ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 ]. Specifically, Adam proposes a modification of the type classes that would back the extension. In the previous design the HasField class is defined as a lens: class HasField (n :: k) r a | r n -> a hasField :: r -> (a -> r, a) The proposal is to replace it by two classes (slightly simplified) class HasField (n :: k) r a | r n -> a hasField :: r -> a class SetField (n::k) r a | r n -> a modifyField :: (a -> a) -> r -> a setField :: a -> r -> a This is originally motivated by some performance consideration: the prototype implementation of HasField as a lens can be very time consuming because instances of HasFields are generated eagerly at record definition sites, whereas the simple HasField instances can simply reuse the selectors already generated by GHC. But a lot of thoughts have been put into the new design, and my summary can certainly not do it justice: the proposal is very well argumented. A point I'll make here is that the new design is actually parametric in the data representation of the field type. Something that wasn't possible in the original design. This proposal is not technically backward compatible, because the order of argument in which OverloadedRecordUpdate expects the argument of setField is changed. This is not essential to the proposal, but this is a more consistent order argument with the rest of Haskell. And considering that OverloadedRecordUpdate is very loudly advertised as experimental, I recommend accepting this breakage. Overall the proposal is actually more backward compatible with GHC 9.8 than the original design, as the HasField class is left unchanged. Overall, the proposal looks quite reasonable to me, and well-argued. I recommend acceptance. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

8 25

Please review #571: -Wsevere, Shepherd: Adam
by Joachim Breitner 11 Oct '23

11 Oct '23

Dear Committee, based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a warning group -Wsevere for on-by-defaults, error-by-default warnings, and initially fill it with missing-methods and missing-fields. https://github.com/ghc-proposals/ghc-proposals/pull/571 https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-… I’d like to nominate Adam as the shepherd, who already reviewed it a bit on Github. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

9 51

Amend or patterns (#522) to use p1 ; p2 (#609)
by Chris Dornan 08 Oct '23

08 Oct '23

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a4… Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance ## Summary This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns. The syntax of the old proposal, ```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ``` is replaced with ```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ``` or indeed ```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ``` (Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.) The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production. ## Recommendation The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

10 22

#526: Applicative Comprehensions (rec: accept)
by Simon Marlow 03 Oct '23

03 Oct '23

Dear committee, #526 proposes a new extension ApplicativeComprehensions (implying MonadComprehensions). It would provide the equivalent of the current ApplicativeDo desugaring for do-expressions to list comprehensions. - Github thread <https://github.com/ghc-proposals/ghc-proposals/pull/526> - Rendered <https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicati…> The extension itself is relatively uncontroversial, but there are some unresolved quirks in the original ApplicativeDo extension which made us uneasy about extending it. However, after various discussions I'm going to propose accepting this proposal in its current state. Rationale: - It doesn't make things worse, and the implementation isn't likely to add significant complexity. - It retains consistency between ApplicativeDo and ApplicativeComprehensions (in contrast to the idea of making ApplicativeComprehensions perform a simpler desugaring, which came up during the discussion) - A future proposal can add a simpler version of the desugaring for both extensions later. Cheers Simon

8 9

Please review #612: -fhpc tix file changes, Shepherd: Moritz
by Joachim Breitner 27 Sep '23

27 Sep '23

Dear Committee, David Binder suggests to change how -fhpc handles existing tix files by default: https://github.com/ghc-proposals/ghc-proposals/pull/612 https://github.com/BinderDavid/ghc-proposals/blob/change-fhpc-semantics/pro… I’d like to nominate Moritz as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Warnings
by Simon Peyton Jones 25 Sep '23

25 Sep '23

Dear GHC SC You may or may not have been following GHC ticket #22141 <https://gitlab.haskell.org/ghc/ghc/-/issues/22141>, and Ryan's merge request !11314 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314>. The story is this: - There is a bug in GHC that allows programs to use DataKinds without the -XDataKinds extension. - The MR fixes the bug. - But of course that will mean that some programs that previously compiled (exploiting the bug) will now fail to compile (correctly). It seems like an example of our (GR2) discussion, but with a very different flavour than the (3+4=8) example. Personally I think we should do it -- with a deprecation cycle saying "You need DataKinds for this program, and you don't have it on, but you will need it in the next release". I don't want us to grandfather bugs into GHC indefinitely -- although you could argue that the status quo does little harm, I suppose. Any views? We will have some idea of the impact on head.hackage shortly. *And specifically: do you want a GHC proposal for this change?* Simon

6 6

Template too large, removed direct link
by Joachim Breitner 18 Sep '23

18 Sep '23

Hi, we used to have a direct link in our README to start a new template pre-filled with the template, but that only worked as long as our template text was short enough to fit into an URL, and would just give an error message now. I have removed that from the README for now. It requires proposal authors to understand enough git to know how to create a new file and copy some other file into it. Maybe not too high a hurdle. We can add the link back if we have shrunk our template to a sensible size again… these things grow like nothing else, besides maybe bureaucracy. If someone makes a heroic effort to make the template more concise without losing anything important (I think the endorsement section can go as it is unused, but that alone is not enough), that would be great! Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

GHC steering committee status
by Simon Peyton Jones 13 Sep '23

13 Sep '23

Dear GHC steering committee Re GHC proposals I was talking to Simon M about - Making the shepherd's job easier and quicker - Providing a way for members of the committee to say (explicitly) "I don't have an opinion about this proposal" and thus recuse themselves. Explicit recusal is better than "silence means assent" because silence can, and often does, mean "I'm under water and not listening". With that in mind, I want to revive my suggestion of running an online spreadsheet <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu…>to describe the state of proposals that are in our active purview. That is, I'm not proposing to show proposals that are under discussion by the community, or accepted etc -- just the ones that are in our inbox, *where the next action is ours.* That makes it much easier to see our current inbox, without looking back for Jocahim's last email and then adding deltas for all the emails since -- which I cannot do in my head. Specifically, I have *a column for each committee member's vote. * That should make it easy for the shepherd to see who is yet to express an opinion, which I always find difficult. As I say above, I am very uncomfortable with "silence means assent" for any but the smallest proposals. *I suggest instead that if there is a proposal where you feel unable to offer an opinion, due to lack of expertise, or lack of time, you can say "recuse" meaning that you explicitly want to stand down from this particular proposal.* (Somehow "abstain" carries a connotation of conflict of interest or something, but it amounts to the same thing.) If you are too under water to even recuse yourself, maybe it's time to step down. So in columns F to O we should see explicit responses from every committee member, in a timely way. Joachim doesn't like spreadsheets like this because they can easily get out of date. But it must be better than manually trawling email. *And it is up to each of us (not Joachim) to fill in our own column for proposals in our inbox.* If we don't like it, we can change it. You all have edit rights. I have populated it with data from Joachim's message of 2 Sept, but there has been some action since then, so shepherds please update it. This is not Joachim's task! Thanks Simon

5 7