- ghc-steering-committee

GHC Committe Chairs term
by Joachim Breitner 22 Dec '23

22 Dec '23

Dear Simon and Simon, your current three terms on the committee end soon (Feb 2024). The bylaws say that you will stay on the committee without renomination and electing if you wish to do so (and the rest of the committee agrees with majority). Therefore I ask: do you want to stay on the committee for another term? (If you do I already register my vote to support this outcome, with four more such votes from non-chair-members we’ll have fulfilled this little ceremony.) Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 2

GHC stability
by Simon Peyton Jones 22 Dec '23

22 Dec '23

Dear Jose, GHC Steering Group, and HF Stability Group There has been quite a lot of recent discussion about actions we could take to promote GHC stability. In an effort to gather these threads together I have written *GHC Staibility State of Play* <https://docs.google.com/document/d/1sX_rXHx8Mj3Kae9GalR2BwZ5-xzl7UpnpMBwl4d…> It articulates the Big Goal, and some discussions that are going on around it. Jose, I think that the Big Goal could be a helpful focus for HF. I'm not sure which of the strands is highest priority (causes most friction for users) so HF's guidance about that would be helpful. It would be great to move some of this forward. Simon

1 0

Please review #626: Visible Forall in Types, Shepherd: Arnaud
by Joachim Breitner 11 Dec '23

11 Dec '23

Dear Committee, Vladislav proposes to support visible forall in types of terms better: https://github.com/ghc-proposals/ghc-proposals/pull/626 https://github.com/ghc-proposals/ghc-proposals/pull/626/files I’d like to nominate Arnaud 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

Please review #624: Linear lets, Shepherd: Richard
by Joachim Breitner 07 Dec '23

07 Dec '23

Dear Committee, Arnaud wants to amend linear types with linear lets: https://github.com/ghc-proposals/ghc-proposals/pull/624 https://github.com/ghc-proposals/ghc-proposals/pull/624/files I’d like to nominate Richard as the shepherd, given that he shepherded the Linear Types. But if you have too much on your plate, feel free to reassign to someone else. 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

GHC2024 committee deliberation
by Joachim Breitner 04 Dec '23

04 Dec '23

Dear Committee, I’d like to get the committe involvement in GHC2024 started. The current proposal is at https://github.com/ghc-proposals/ghc-proposals/pull/613 https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposa… At the moment, six changes relative to CHC2021 are proposed by committee and by community members. See the proposal for rationales. My goal is to have a decision in time for 9.10. I suggest we use November to deliberate the proposals and maybe add more changes to the list, and then vote in early December. We’ll put each change separately on the ballot. I know that there are ongoing discussions that could arguably affect how we want the next GHC20xx to look like, in particular the just opened #620, and I anticipate a desire to postpone GHC2024 until that has been decided. But I recall that we postponed GHC2023 for (among other reasons) for the same reason, and I wouldn’t be surprised that if in a year we have yet another unresolved question that seems worth waiting for. If this pattern reminds you of the GHC release process before we introduced the regular cadence, then maybe you’ll agree that if we want a predictable and reasonable frequent stream of language editions, we have to avoid such delays when feasible. So please let us know what you think of the proposed changes, what other changes you want to see, or if you have qualms about the process. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 19

Please review #606: 281 to use atype instead of ktype, Shepherd: Richard
by Joachim Breitner 30 Nov '23

30 Nov '23

Dear Committee, Vladislav Zavialov proposes a grammar amendment to types in terms: https://github.com/ghc-proposals/ghc-proposals/pull/606 https://github.com/ghc-proposals/ghc-proposals/pull/606/files I’d like to nominate Richard 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

GHC stability discussions
by Simon Peyton Jones 09 Nov '23

09 Nov '23

Dear GHC Steering Committee We have several threads about GHC's stability in progress: - Proposal 601: GHC extension life cycle <https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycl…>. This introduces the notion of a "Stable" and "Experimental" extension. It was written by David C but has stalled now that he has stepped down as ED. - GHC Stability Goals <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47Zulg…>, builds on #601 with general rules GR1-3. This is not a change to GHC (hence not a GHC proposal) more a clarification about how the GHC Steering Committee works. - Proposal 620: Extensions and warnings <https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-extensions-and-…>. This proposal keeps moving in the same direction, unifying warnings and extensions. - Proposal 617: add -experimental flag <https://github.com/ghc-proposals/ghc-proposals/pull/617>. This builds on #601 by providing an enforcement mechanism. It is strongly affected by #620. It would be good to get some of this decided. Too much is in the air at the moment! Personally I think: - We can agree at least the Stable/Experimental part of #601 - The Stability Goals seem fairly uncontroversial. Shall we just make it part of the GHC Proposal process documentation - #620 is new; your views would be welcome - The approach to #617 may depend on the outcome of #620. Simon

2 3

#536: Type-level literals as a separate language extension
by Vladislav Zavialov 20 Oct '23

20 Oct '23

Dear Committee, Back in March I initiated a discussion of #536 "Type-level literals as a separate language extension" by Ross Paterson. Quick recap: currently DataKinds controls promotion of ADTs and Symbol/Natural/Char literals. The proposal is to factor out promotion of literals into their own extension, TypeLevelLiterals. I recommended acceptance but received mixed feedback. Summary of opinions: Vlad: "rec: accept" SPJ: "content to accept" Joachim: "unsure how that fits with the overall direction we have for namespaces" Arnaud: "unconvinced that it is worth yet one extra extension" Richard: "pretty strongly against" Adam: "avoid bundling together distinct features" (i.e. accept) Chris: "in favour" Iavor (as ex-member): "strongly in favor" Haven't yet expressed their opinion: Simon M. and Moritz. So we have roughly 5 votes in-favor-or-don't-mind and 3 votes against-or-unconvinced. SPJ suggested that we simply count the votes, but after reading the discussion, I find that there's a deeper reason for disagreement. Essentially, we have two camps: 1. "Let a thousand flowers bloom": Haskell should be customizable, built out of small extensions à la carte. (A necessary implication here is that this gives rise to dialects of Haskell that depend on the set of enabled extensions) 2. "More extensions make me wince": Extensions are a necessary evil while we explore the language design space, and we shouldn't create them unnecessarily. (Language editions like GHC2021 help with that, allowing the users to forget about individual extensions and simply use a better/newer Haskell) The 1st paradigm suggests that TypeLevelLiterals should be factored out. TypeLevelLiterals+TypeData form a dialect different from DataKinds with regards to name resolution, which some users might prefer. Let them have it, why not? The 2nd paradigm suggests that breaking DataKinds into smaller extensions is counterproductive. Do we want fewer extensions or more extensions, after all? And as a steering committee, don't we have a clear direction in which we steer? Unfortunately, we don't have a general policy that would clearly tell us which camp/paradigm is right. And it's about time that we make a decision regarding #536, even if we don't have a policy to guide us. Because of that, my new plan is to reject the proposal out of caution. We have at least one "strongly against", and it's enough to give me pause. It's probably better to stick to the status quo, at least until we develop a concrete stance w.r.t. fine-grained extensions. (Pardon a digression, but this also calls into question whether 448 is justified in splitting ScopedTypeVariables into ExtendedForAllScope, MethodTypeVariables, PatternSignatures. Maybe we don't want fine-grained extensions after all) The new recommendation is to reject the proposal, but I still can't make this decision single-handedly. So let's do another round of discussion, only this time let's stick to practicalities, not general considerations. Is there anyone on the committee (or do we know someone) who needs TypeLevelLiterals for practical reasons, not just as a matter of taste? For example, 1. You are writing a book and you want to introduce TypeLevelLiterals before DataKinds 2. You are developing or maintaining a library or application that needs TypeLevelLiterals but cannot use DataKinds 3. You are working on an alternative Haskell implementation and intend to support TypeLevelLiterals but not DataKinds If any of the above (or similar) applies, speak up. Vlad

7 8

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