August 2023 - ghc-steering-committee

#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 #601: Extension lifecycle, Shepherd: Simon PJ
by Joachim Breitner 03 Sep '23

03 Sep '23

Dear Committee, David Thrane Christiansen suggested to categorize extensions into Experimental, Mature, Deprecated and Legacy, and add warning flag to GHC that allow users to be warned about (or shouted at for) using such extensions, if they choose so. https://github.com/ghc-proposals/ghc-proposals/pull/601 https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycl… Because of the meta-like aspect of this proposal, I’d like to assign this to Simon PJ. 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/

10 22

Please review #194: Updated partial type signatures, Shepherd: Eric
by Joachim Breitner 03 Sep '23

03 Sep '23

Dear Committee, Richard resubmits updated partial type signatures: https://github.com/ghc-proposals/ghc-proposals/pull/194 https://github.com/goldfirere/ghc-proposals/blob/updated-partial-type-sigs/… I’d like to ask Eric 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(a)joachim-breitner.de http://www.joachim-breitner.de/

2 4

#607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept)
by Vladislav 02 Sep '23

02 Sep '23

Dear Committee, Jakob Brünker has proposed #607, an amendment to proposals #281 (visible forall) and #378 (Design of DH). See the diff here: <https://github.com/ghc-proposals/ghc-proposals/pull/607/files> The amendment concerns type checking of term-level variables appearing in types, for example: f :: forall (a :: Bool) -> ... -- visible forall, `f` expects a type-level Bool g :: Bool -> ... -- ordinary arrow, `g` expects a term-level Bool g x = f x What should happen to `x`, bound as a term variable but used as a type? #378 "Design for Dependent Types" already has an answer to this question: treat `x` as a skolem. But there are two problems 1. #378 does not explain this design decision in sufficient detail. This led Simon to question its inclusion: "Does it have any value, really? Why not just reject?" 2. #281 follows this design in one section, saying "treated as a fresh skolem constant"; and rejects it in another section, saying "any uses of terms in types are ill-typed". There is a contradiction. The amendment addresses both issues as follows: 1. A new example is added to #378, explaining how treating `x` as a skolem is useful, but only if `foreach` is available (a retained quantifier that allows dependent pattern matching) 2. Contradiction in #281 is resolved in favor of rejecting any uses of terms in types as ill-typed, saving this feature for a future proposal. I recommend to accept. Please share your thoughts either here or directly on GitHub. Vlad

7 7

#605: visible forall to work without ScopedTypeVariables, rec: accept
by Joachim Breitner 02 Sep '23

02 Sep '23

Dear committee, Vladislav Zavialov in https://github.com/ghc-proposals/ghc-proposals/pull/605 proposes a small fix to #281, namely that for f :: forall x -> Show x => x -> String f (type t) = show @t to work, ExplicitNamespaces and RequiredTypeArguments is sufficient, and we should not also require ScopedTypeVariables, which we are moving away from. I’ll shepherd this myself, and I suggest acceptance. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 5

Language Extension Policy – Round 3
by Arnaud Spiwack 30 Aug '23

30 Aug '23

Dear all, For this round, I'd like to build on the results of last round [1]. One thing that strikes me in the results, bearing in mind that 6 out of 10 members answered the question directly, and that none of this is without dissent anyway, is that there seems to be a general feeling that extension should not stay forever. What I'm reading is that most respondents seem to believe that when an extension becomes part of GHC20xx, it should be removed (with a deprecation period, I'd imagine): if you want the feature, use GHC20xx. Now, before I explore this question further, I should acknowledge that this doesn't directly help answering the questions that I set to resolve when this all began. Namely, under what principles do we judge extensions (in particular whether a proposal should be one of several extensions). But I think it's likely to help. I'm starting with this conversation because it's relatively concrete, probably less controversial than other questions, and as such, I'm hoping that it'll help us discuss the more difficult questions with a little more understanding of what we collectively believe. Let's explore what it would mean for an extension to be removed. - The extension wouldn't appear in `$ ghc --show-options` (currently `$ ghc --show-options | grep '\-X'` has 268 lines, almost every extension accounts for 2 lines) - The programmer can't turn the extension on or off directly - The documentation, in the user manual, of the corresponding feature would be moved from the “Language extension” section to somewhere else (maybe a new section “Language features”? Not sure what is natural here) - Error messages about the feature not being activated would stop suggesting you use the extension, but instead that you use one of the appropriate GHC20xx. - For some extension, we could provide a warning (off by default) to allow those who want to avoid the corresponding to disallow it in their codebase. But certainly not all extensions would be turned into warnings: I don't anticipate anybody will want to specifically avoid -XBinaryLiteral for instance. - Am I forgetting something? It doesn't mean that the extension must disappear in the implementation of GHC: this is an implementation detail (maybe it'll be beneficial for some extensions to be removed and other not, I don't feel capable of anticipating this). But the extension would not be visible or accessible to the user. Now the question is: ignoring the question of whether we have time to retroactively do this, does this look like this would be part of your ideal vision for GHC. If not, please argue. [1] https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmec… -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

8 12

Please review #607: Amendments clarify treatment of term variables in types, Shepherd: Vlad
by Joachim Breitner 19 Aug '23

19 Aug '23

Dear Committee, Jakob Brünker spotted some inconsistencies in 281 (visible forall) and #378 (Design of DH): https://github.com/ghc-proposals/ghc-proposals/pull/607 I’d like to assign this to Vlad. 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 #609: (p1; p2) for or-patterns, Shepherd: Chris
by Joachim Breitner 17 Aug '23

17 Aug '23

Dear Committee, Sebastian Graf and David Knothe have reasons to revisit the Or-patterns proposal (#522) and change the syntax, also based on a series of popular votes. https://github.com/ghc-proposals/ghc-proposals/pull/609 I’d like to assign this to Chris Dornan. 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 #583: HasField redesign, Shepherd: Arnaud
by Joachim Breitner 17 Aug '23

17 Aug '23

Dear Committee, Adam Gundry proposes an overhaul of the HasField type class. https://github.com/ghc-proposals/ghc-proposals/pull/583 https://github.com/adamgundry/ghc-proposals/blob/hasfield-redesign/proposal… I’d like to assign this to Arnaud. 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 #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard
by Joachim Breitner 17 Aug '23

17 Aug '23

Dear Committee, John Ericson continues his series of amendments to #448 (Modern Scoped Type Variables); in #608 he scales back -XPatternSignatures so that it does not include pattern signature bindings. This is quite similar to my #119 from 5 years ago. https://github.com/ghc-proposals/ghc-proposals/pull/608 I’d like to assign this to Richard as one of the experts on scoped type variables. 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