- ghc-steering-committee

Re: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept
by Joachim Breitner 15 Dec '22

15 Dec '22

(replying to the whole list, full quote) Am Donnerstag, dem 08.12.2022 um 11:23 +0300 schrieb Vladislav Zavialov: > I agree with your observation that namespaced imports are somewhat > different from simply specifying the namespace of a single name, so > they could be separated into their own extension. But if that is the > reasoning that we choose to follow, then the changes in #281 should > *definitely* go into their own extension: they affect not just names > but entire expressions and patterns, including their grammar (not > just namespacing). > > The only reason the changes in #270 and #281 are included in > ExplicitNamespaces is to reduce the amount of language flags. If you > prefer fine-grained control and immutable extensions, then both of > those changes need separate flags for them. > > So, if we are consistent, we have two options: > 1. Include changes in #270 and #281 in ExplicitNamespaces on the > grounds that they include explicitly specify a namespace (even though > that is not the only thing they do) > 2. Create separate language extension flags: NamespacedImports and > TypesInExpressions (names to be discussed) > > I happen to prefer (1), and that is the approach that the proposals > currently follow, but I am not opposed to (2) either. I don’t prefer fine-grained flags per se. In fact, my ideal world is one perfect language with no flags :-). So I think I’d prefer all under ExplicitNamespaces as well, and I think the only reason I am hesitant is that I believe the old ExplicitNamespaces should have been in GHC2021, so it should be in GHC2023, and am unsure if the (comprehensive) ExplicitNamespaces should be there. This gives us (at least) these options: 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, introduce one or two new extensions for the newer changes. 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, disregarding issue #551. 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, arguing that GHC20xx allows more liberal (backward-compatibile) changes than, say, Haskell2010 would allow. Certainly 1 is the least bold move. I am not sure what the best way forwards is, and welcome other opinions. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 17

Re: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept
by Adam Gundry 12 Dec '22

12 Dec '22

(Simon, I'm guessing this message should have gone to the committee list, so I'm including the full text below.) On 12/12/2022 13:04, Simon Peyton Jones wrote: > > The nested use is already possible with ExplicitNamespaces. > Currently it > > > Wow. I had no idea. The user manual is entirely silent on this point > <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/explicit_namespaces…>. > Is there some proposal that specifies this behaviour, which the user > manual is failing to document? Or is the implementation doing > something that is nowhere specified? > > I'm trying to understand what `import M type (MkT)` does > > > Well the proposal says > # With |type| specified in the import, only identifiers belonging to the > type namespace will be brought into the scope. > I took this saying "behave exactly as now, but post-filter the imports > to take only the ones from the type namespace". Today `import M( MkT > )` will be rejected; so I assume it'll still be rejected. > > I agree that this point could be more clearly articulated. > > Simon > > On Mon, 12 Dec 2022 at 12:22, Adam Gundry <adam(a)well-typed.com> wrote: > > On 12/12/2022 11:39, Simon Peyton Jones wrote: > > {-# LANGUAGE ExplicitNamespaces #-} > > module N where > > import M (T(type MkT)) -- NB "type" import of a data > constructor > > v = MkT -- usage at term level > > > > > > Crumbs. I had not realised the proposal is to allow *nested* > uses of > > 'type' in import lists, as you show above. > > The nested use is already possible with ExplicitNamespaces. > Currently it > allows > > import M (T(type MkT)) > import M (type MkT) > import M (pattern MkT) > > whereas the proposal extends it to add the possibility to write > > import M type (MkT) > import M data (MkT) > import M (data MkT) > > > > In general, I don't feel the extensions to > ExplicitNamespaces included > > in the proposal are very clearly specified. > > > > > > Actually isn't the proposal pretty clear on this, namely the first > > bullet of proposed change spec > > > <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support…>. > It only covers > > import M *type * > > import M *data *as MD > > where I have emboldened the new bits. Nothing about the > contents of > > import lists. Why did you think your example is covered by the > proposal? > > I'm trying to understand what > > import M type (MkT) > > means where MkT is a data constructor (or if it raises some kind of > error). This was by analogy to the existing > > import M (T(type MkT)) > > which means something today, albeit not necessarily a very sensible > thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581) > > I don't see a clear specification of the proposed (extended) > semantics > of ExplicitNamespaces in the proposal, but perhaps I've missed > something? > > Cheers, > > Adam > > > > On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam(a)well-typed.com > > <mailto:adam@well-typed.com>> wrote: > > > > Actually, reading > https://gitlab.haskell.org/ghc/ghc/-/issues/22581 > > <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> I > > realised I'm unclear how the proposed extensions to > ExplicitNamespaces > > are supposed to work. The existing situation is apparently > that for a > > (non-punned) data constructor, it is possible to use either a > > pattern or > > type qualifier in an import list (presumably because > DataKinds means > > the > > constructor is in scope at both the term and type levels), > and the > > imported constructor is then usable in both contexts. > > > > For example, the following is accepted at present: > > > > module M where > > data T = MkT > > > > {-# LANGUAGE ExplicitNamespaces #-} > > module N where > > import M (T(type MkT)) -- NB "type" import of a data > constructor > > v = MkT -- usage at term level > > > > The present proposal says "With type specified in the > import, only > > identifiers belonging to the type namespace will be brought > into the > > scope." I'm not exactly sure how to interpret this, does it > mean the > > following alternative will be accepted or rejected? > > > > module N where > > import M type (MkT) > > v = MkT > > > > I'm worried we will end up with a situation where > ExplicitNamespaces > > does subtly different things depending on the position of > the keyword. > > > > In general, I don't feel the extensions to > ExplicitNamespaces included > > in the proposal are very clearly specified. Given the > discussion about > > exactly which parts belong to > ExplicitNamespaces/PatternSynonyms versus > > separate extensions, perhaps we should accept the parts > relating to > > -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces > changes to be > > proposed separately? > > > > Cheers, > > > > Adam > > > > > > On 09/12/2022 11:11, Adam Gundry wrote: > > > I'm broadly in favour of accepting the proposal. I > realise the > > history > > > is complex here, so I don't think we should ask anyone to > rewrite > > things > > > further, though in general it would be nicer to have separate > > proposals > > > for -Wpuns/-Wpun-bindings (which is unambiguously fine) > and for the > > > changes to imports (which as Joachim points out raise > issues). > > > > > > I'm a bit concerned that the proposal does not motivate > or specify > > > -Wpattern-namespace-qualified very well. > > > > > > > > > On 08/12/2022 08:33, Joachim Breitner wrote: > > >> ... > > >> > > >> This gives us (at least) these options: > > >> > > >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to > > GHC2023, > > >> introduce one or two new extensions for the newer > changes. > > >> 2. Extend ExplicitNamespaces, and don’t add it already > to GHC2023, > > >> disregarding issue #551. > > >> 3. Add ExplicitNamespaces to GHC2023, and still add it > to GHC2023, > > >> arguing that GHC20xx allows more liberal > (backward-compatibile) > > >> changes than, say, Haskell2010 would allow. > > >> > > >> Certainly 1 is the least bold move. I am not sure what > the best way > > >> forwards is, and welcome other opinions. > > > > > > I would prefer a variant of 1: allow "data" as a keyword in > > import lists > > > under ExplicitNamespaces, but make the other changes > under other > > > extensions. > > > > > > As I've said previously, I have a general preference for > multiple > > small, > > > orthogonal extensions rather than changing existing > extensions to > > add > > > unrelated features that happen to be in similar > territory. I realise > > > this is controversial, of course. > > > > > > 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

1 0

#556: multiple type variables in signatures in type applications in patterns, Recommendation: accept
by Joachim Breitner 09 Dec '22

09 Dec '22

Dear all, Vlad has submitted a bug fix amendment to #448, to fix the wording around type variables in signatures within explicit type annotations: https://github.com/ghc-proposals/ghc-proposals/pull/556/files I’m shepherding that one myself. The gist is that in data Proxy a = P g :: Proxy (Nothing @(a, a)) -> () g (P @(Nothing :: Maybe (x, x))) = () the multiple occurrences of `a` are non-linear patterns and disallowed, but the multiple patterns of `x` are fine, because that’s how type variables in signatures in patterns happen to work. Vlad fixed the wording with regard to that in #448. Simon and Richard already signaled support on the Github thread, which I recommend to follow. I don’t expect much further discussion around this and will happily merge after a week of silence (or after one or two additional confirmations). Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Proposal #270: Support pun-free code. Recommendation: accept
by Chris Dornan 08 Dec '22

08 Dec '22

Hi all, I have been assigned to shepherd 'Proposal #270: Support pun-free code’ and this is my second attempt to reach a conclusion (see below for for my original encapsulation of the proposal). As I said, my outstanding concern was that some could see this proposal as a green-lighting a general move against the use of these puns in general Haskell code as ‘bad style. The author has now clarified in the proposal that it should not be seen in this light. Unless anyone has any outstanding objections I suggest the we accept the proposal — or at least hold an up-and-down vote to resolve whether we are going to accept the proposal or not. I vote yes to accepting this proposal. Chris — My original summary: Proposal text: https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support… <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support…> Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/270 <https://github.com/ghc-proposals/ghc-proposals/pull/270> The proposal helps manage @data T = T@ style definitions that use the same name for type and data constructors. It introduces -Wpuns and -Wpun-bind to warn about puns at usage and binding sites, respectively, and adds qualified import syntax for importing selectively into the data and type name spaces: import Data.Proxy type qualified as T -- import only the type namespace import Data.Proxy data qualified as D -- import only the data namespace As the low number indicates the proposal has been around for a while and the author has an implementation PR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2044 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2044>. The most active discussion point was Simon’s observation that this extension introduces a ‘fork’ in the language: https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115… <https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115…>. (See Simon’s comment at the link for an explanation of the Haskell language fork idea.) There is a long tradition of using data/type constructor puns (older than Haskell itself) and many people will consider it good style (I certainly do), while others do not, and they will benefit from tools to help manage and limit their use. So, notwithstanding the fork-like nature of the proposal, because it is not very intrusive (some warnings with finer control of qualified imports), and it is helping folks to establish a subset that they are maintaining anyway, I am minded to accept this proposal — though it was close. My sole concern is that it could give rise to contentious pressure on the wider Haskell community to embrace the subset. To (avoiding) this end, I suggest that we include wording in the user guide section documenting this extension to the effect that there is no consensus on the desirability or otherwise of the punful code the extension seeks to address.

4 7

GHC Steering Committee Status
by Joachim Breitner 29 Nov '22

29 Nov '22

Dear Committee, let’s do another ~bi~trimonthly status update. There was an uptick in submissions recently, and our backlog is on the large side; it looks like almost everyone So what has happened since the last one? * Baldur has stepped down, Arnaud has renewed their term and Adam Gundy joined. Thanks all! * I started a discussion on whether we should have GHC2021. I sense some hesitation, but not enough yet to discourage me, so I stated to draft a proposal at https://github.com/ghc-proposals/ghc-proposals/pull/559 and you are all invited to nominate those extensions you’d like to be on by default in the future. * we were asked to review these proposals: #532: Clean up implicit binding, Shepherd: Arnaud #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad #526: Applicative Comprehensions, Shepherd: Simon M #540: parallelism semaphores, Shepherd: Eric #547: Remove kind constraints, Shepherd: Arnaud #529: Template Haskell quotes as patterns, Shepherd: Adam #451: WARNING pragma with category, Shepherd: Joachim #546: Make Symbol a newtype over String, Shepherd: Chris #556: fix signature scoping #448, Shepherd: Richard * we have a recommendation from the shepherd about: #522: Or patterns. Recommendation: accept #516: Introduce `-Wincomplete-record-selectors`, Rec: accept #270: Support pun-free code. Rec: accept #500: Add implicit import proposal, rec: reject #547: Remove kind constraints, Recommendation: accept #451: WARNING pragma with category, rec: accept * we have sent the following proposals back to revision (none) * we decided about the following proposals #517: Require implementors before proposal submission (reject) #516: Introduce `-Wincomplete-record-selectors (accept) #547: Remove kind constraints, Recommendation: accept #500: Add implicit import proposal (reject) We currently have to act on the following 12 proposals, double the number as last time! ## Waiting for committee decision #270: Support pun-free code, Shepherd: Chris 2022-01-01: Assigned to Chris 2022-08-24: Chris suggests acceptance 2022-09-08: Last message Chris, can you conclude this discussion? #515 Relaxing HasField constraints 2022-08-01: Assigned to Tom 2022-08-10: Tom suggests acceptance Still no comments. Tom, please drive this discussion! #522: Or Patterns 2022-08-08: Assigned to Richard 2022-08-19: Richard recommends acceptance 2022-10-18: Last message Richard, is this discussion converging? #451: WARNING pragma with category, Shepherd: Joachim Acceptance seems imminent ## Waiting for shepherd recommendation #330: Decorate exceptions with backtrace information, Shepherd: Vlad 2022-06-25: Assignd to Vlad This seems to have fallen through the cracks. Vlad, please make a recommendation! #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad 2022-09-03: Assignd to Baldur 2022-10-02: Reassignd to Vlad #526: Applicative Comprehensions, Shepherd: Simon M 2022-10-08: Assigned to Simon M #529: Template Haskell quotes as patterns, Shepherd: Adam 2022-11-16: Assigned to Adam #532: Clean up implicit binding, Shepherd: Arnaud 2022-08-23: Assigned to Arnaud Sent back for revision 2022-11-27: Resubmitted #540: parallelism semaphores, Shepherd: Eric 2022-11-08: Assigned to Adam 2022-11-17: Re-assigned to Eric #546: Make Symbol a newtype over String, Shepherd: Chris 2022-11-18: Assigned to Chris #556: fix signature scoping #448, Shepherd: Richard 2022-11-27: Assigned to Richard Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 3

Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Decorate exceptions with backtrace information (#330)
by Simon Peyton Jones 29 Nov '22

29 Nov '22

Vlad Thank you for such a thorough job! You are an example to us all. Simon On Tue, 29 Nov 2022 at 10:56, Vladislav Zavialov <notifications(a)github.com> wrote: > Hi @bgamari <https://github.com/bgamari>! I have finished another round > of review and identified a few potential improvements. > > 1. > > *Proposal structure.* At the moment, the "Proposed Change > Specification" section contains a lot of information in addition to the > specification itself. It's mixed with exposition and > implementation-specific code snippets. Instead, I expect to see a concise > list (bulleted or numbered) of proposed changes, as seen from the end-user > perspective. Undoubtedly, the rest of the prose is also valuable, so I ask > you not to remove it but to distribute it across other sections of the > proposal text. > 2. > > *Make ExceptionContext opaque.* The proposal define ExceptionContext > as a wrapper around [SomeExceptionAnnotation], but should we expose > this fact to our users? What if we decide to store additional information > there? I believe it would be best not to export the data constructor to > allow for future changes. > 3. > > *Remove the Semigroup instance for ExceptionContext*. The annotations > are stored in a list, so (<>) is O(n), and that's not good. > Furthermore, I can't think of a use case for appending annotations from > different exceptions, so there's a simple way to address this: do not > define Semigroup or Monoid instances. > 4. > > *Semantics of ExceptionContext.* The list of SomeExceptionAnnotation > is ordered, so we ought to define how users can interpret this order. What > does it mean for one annotation to come before another? Here's an idea: > introduce an operation similar to checkpoint > <https://hackage.haskell.org/package/annotated-exception-0.2.0.4/docs/Contro…> > from annotated-exceptions: > > annotateIO :: ExceptionAnnotation a => a -> IO r -> IO r > > The order of SomeExceptionAnnotation would reflect the nesting of > calls to annotateIO, reflecting the call stack in its own way > (separately from the collected backtraces). > 5. > > *Group backtraces in a record.* If we say that a single element in > SomeExceptionAnnotation corresponds to a call to annotateIO, it is > somewhat strange to add multiple annotations for a single event of > collecting backtraces. After all, what would it mean for the > HasCallStack backtraces to come before the CostCentre backtrace or > vice versa? So introduce a record to store them together: > > data Backtraces = > Backtraces { > costCentreBacktrace :: Maybe (Ptr CostCentreStack), > hasCallStackBacktrace :: Maybe GHC.Stack.CallStack, > executionBacktrace :: Maybe [GHC.ExecutionStack.Location], > ipeBacktrace :: Maybe [StackEntry] > } > > (I refine this idea in the next suggestion) > 6. > > *Encode the Backtraces record with GADTs*. The record type Backtraces > that I suggest in the previous point introduces a slightly annoying form of > code duplication. The proposal already has an enumeration of backtrace > mechanisms: > > data BacktraceMechanism > = CostCenterBacktraceMech > | ExecutionStackBacktraceMech > | IPEBacktraceMech > | HasCallStackBacktraceMech > > And in the record, we have a field per mechanism, each wrapped in a > Maybe. Fortunately, there is an encoding that removes this > duplication. Let us index BacktraceMechanism by the representation > type of the backtrace: > > data BacktraceMechanism a where > CostCentreBacktrace :: BacktraceMechanism (Ptr CostCentreStack) > HasCallStackBacktrace :: BacktraceMechanism GHC.Stack.CallStack > ExecutionBacktrace :: BacktraceMechanism [GHC.ExecutionStack.Location] > IPEBacktrace :: BacktraceMechanism [StackEntry] > > Now we can encode the set of enabled mechanisms as a function to Bool > and the record of collected backtraces as a function to Maybe a. > Something along the lines of: > > type EnabledBacktraceMechanisms = forall a. BacktraceMechanism a -> Booltype Backtraces = forall a. BacktraceMechanism a -> Maybe a > > This isn't as low-tech as a an enum and a record, and I realize that > low-tech solutions are appealing in their own way, but in this particular > case, I find that GADTs offer a more elegant encoding. > 7. > > *Hide the implicit parameter behind a synonym*. We choose to pass > around the exception context as an implicit parameter, but this should be > hidden from the end user. This is the way it's done with HasCallStack, > where documentation clearly states: > > NOTE: The implicit parameter ?callStack :: CallStack is an > implementation > detail and *should not* be considered part of the CallStack API, we may > decide to change the implementation in the future. > > Let's do the same and introduce a synonym for exception contexts: > > type HasExceptionContext = (?exceptionContext :: ExceptionContext) > > 8. > > *Preserve backtraces on rethrowing*. The way the proposal is currently > written, when an exception is caught and rethrown, its old backtrace is > dropped and a new one is constructed. This is very bad, because rethrowing > happens all the time (e.g. in bracket)! But it is not hard to fix: > catch should provide the context to the handler as an implicit > parameter, and throw should make use of it: > > catch :: Exception e => IO a -> (HasExceptionContext => e -> IO a) -> IO athrowIO :: (HasExceptionContext, Exception e) => e -> IO a > > What about uses of throwIO where HasExceptionContext has not been > provided by catch? Easy: default to an empty context. It shouldn't be > hard to add this special case to the solver, since HasCallStack has > already set a precedent. > 9. > > *Get rid of toExceptionWithContext*. The proposal introduces a new > method to Exception: > > toException :: Exception e => e -> SomeException -- oldtoExceptionWithContext :: Exception e => e -> ExceptionContext -> SomeException -- new > > But if we are passing the context as a constraint, then we could > simply add it to the original method: > > toException :: (HasExceptionContext, Exception e) => e -> SomeException > > There is no need for two methods this way. > 10. > > *Improvements to throwIONoBacktrace*. Currently the proposal defines > NoBacktrace variants of throw and throwIO: > > throwNoBacktrace :: forall e a. (Exception e) => e -> athrowIONoBacktrace :: forall e a. (Exception e) => e -> a > > The idea is to allow users to opt out of backtraces for > non-exceptional control flow. But the problem is that this choice is not > recorded anywhere in the exception, so when the exception is caught and > rethrown, it will have unwanted backtraces added to it. > > One solution is to add a Bool flag to ExceptionContext to record the > choice of not collecting the backtraces, so that they are not collected > when the exception is rethrown. In fact, we could avoid the duplication of > throw and throwIO this way: > > backtracesEnabled :: HasExceptionContext => BoolenableBacktraces, disableBacktraces :: (HasExceptionContext => r) -> (HasExceptionContext => r) > throw :: (HasExceptionContext, Exception e) => e -> IO athrowIO :: (HasExceptionContext, Exception e) => e -> IO a > > throw and throwIO can check for backtracesEnabled before calling > collectBacktraces. The users would write something along the lines of: > > disableBacktraces $ > throwIO MyControlFlowException > > And the choice to disable backtraces would be carried along the > exception in its context. > > Hopefully, I have not missed anything. In the process of writing this > review, I took a stab at rewriting the "Proposed Change Specification" > section in accordance with all of the suggestions above, mainly to convince > myself that the combination of those suggestions forms a coherent design. > You can find it here: > https://gist.github.com/int-index/750c6c292eb8266729adc61a5812a581. If > you agree with my comments, feel free to incorporate the updated > specification (or parts of it) into the proposal. > > Thank you! > > — > Reply to this email directly, view it on GitHub > <https://github.com/ghc-proposals/ghc-proposals/pull/330#issuecomment-133044…>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAEOY6ZVMSEXYJ6E3PRAMG3WK…> > . > You are receiving this because you are subscribed to this thread.Message > ID: <ghc-proposals%2Fghc-proposals%2Fpull%2F330%2Fc1330446106(a)github.com> >

1 0

#547: Remove kind constraints, Recommendation: accept
by Arnaud Spiwack 25 Nov '22

25 Nov '22

Dear all, Our own Richard and Simon PJ are proposing to remove kind constraints from GHC https://github.com/ghc-proposals/ghc-proposals/pull/547 What are they? Well, exactly. It is a little known feature that you can add constraints in kinds. Actually, you can only have equality constraints (e.g. a~Boo => t -> Type (I actually wanted to write Bool, but I decided to keep the typo in honour of the season)), class constraints are already forbidden. The feature is of limited use because you are not allowed to actually use the constraint when writing instances of such a kind. It's purely a restriction (much like data type contexts). Richard describes the feature as having been implemented because it was easy, not because it was answering a particular need (though it is possible to find applications). Richard and Simon have a problem with this not-very-useful feature: its mere existence makes their plan to properly separate Constraints and Types in Core much harder. So they want to just get rid of it. Now, it's difficult to estimate how much this feature is actually used. As we've learnt the hard way with the simplified subsumption proposal. I'd honestly be surprised if there was actually no usage of kind constraints in the wild. So there is always a risk. But I think that this is a fairly safe bet that very few people have actually used this feature. On the other hand the Constraint/Type separation is long overdue. It seems to me that removing the feature is the right call. I recommend acceptance. /Arnaud

3 7

GHC2023
by Joachim Breitner 11 Nov '22

11 Nov '22

Hi Committee, when we defined the process for GHC20xx, as written in https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-g… we wrote Likely, the first iteration of this process will be vastly different from the following ones: The first one is expected to add a large number of uncontroversial extensions; so the next iteration will likely only make a smaller, but more controversial change. Therefore, this proposal does not commit to a fixed cadence. Instead, 6 months after the first release of a version of GHC that supports a GHC20xx set, we evaluate the outcome, the process, and the perceived need of a next release. At that time we will refine the processes, if needed, and set a cadence. The first version of GHC that supported GHC2021 was 9.2, released in October 2022. Last fall we said that not enough time has passed to do such an evaluation, and we skipped defining GHC2022. Another year has passed, and if we are serious with the idea that GHC20xx is a continuous thing, we should probably start defining GHC2023 – even if it is just a small delta. This e-mail tries to kickstart that process. Last time we did a relative elaborate thing where we voted on essentially _every_ extension. I think that made sense for the first iteration, where we had to winddow down the likely extensions. But now we have a base line (GHC2021), and are asked to find a suitable delta, and I’d go for a nomination-based approach: Committee members can propose adding (or removing, in theory) specific extensions, and then we vote only on those. Does that sound reasonable? Does anyone have any insight from the real world? Has GHC2021 helped our users? And if not, why not? What kind of hard data would you like to see, if any? (I’m a bit wary of spending too much time writing scripts to scrape hackage, for example to see which extensions people tend to enable _in addition_ to GHC2021, only to see that libraries on hackage are understandably slow to use default-language: GHC2021, as that’s not great for backward compat for now. But I am also not sure where to look for good data…) Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 8

Welcome Adam, welcome back Arnaud
by Joachim Breitner 03 Nov '22

03 Nov '22

Dear all, Adam Gundry has nominated himself to join the committee, and was voted in, so welcome! Adam, if you haven’t done so already, please subscribe to https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee and review the processes at https://github.com/ghc-proposals/ghc-proposals/ https://github.com/ghc-proposals/ghc-proposals/blob/master/acceptance.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst You should have gotten a github invite to the repo. Your opinion is valued on all proposals currently under review, even those that were submitted before. Which, conveniently, is only one at the moment and relates to records: https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+la… (but we do look forward to your opinion about proposals about other corners of the language, of course :-)) Arnaud has also nominated himself and was voted back in for another term. Thanks for staying with us! Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 4

Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ
by Joachim Breitner 19 Oct '22

19 Oct '22

Dear Committee, I have submitted a meta-proposal to require implementors to be named before proposal submission, to focus on those proposals that are likely to be actually implemented. https://github.com/ghc-proposals/ghc-proposals/pull/517 Because this is a process-related proposal, I’d like to ask Simon to shepherd it. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

9 23