- ghc-steering-committee

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/ghc-proposals/pull/330/c1330446106(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 12 Nov '22

12 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

Proposal #522: Or patterns. Recommendation: accept
by Richard Eisenberg 18 Oct '22

18 Oct '22

Hi all, I have been assigned to shepherd Proposal #522, Or patterns. Proposal text: https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patt… Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/522 The proposal introduces a syntax for or-patterns. Here is an example: case ... of K1 a b c -> Just ... K2 d e -> Just ... (K3 {} ; K4 {} ; K5 {}) -> Nothing Summary Without this proposal, the author of the above code would have to either use a _ pattern for the last line, meaning that future new constructors added to the datatype would go unreported by compiler warnings, or to write the K3, K4, and K5 cases separately, repeating the right-hand side. Or-patterns are common in other languages. The authors include a nice section (https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patt…) on alternative syntax. I recommend reading it; it made me feel better about the proposed semi-colon syntax. The proposal requires that each pattern in an or-pattern must not bind any variables. Any provided contexts (e.g. GADT equalities) and existential variables are ignored, and any required context is combined across the disjuncts in the pattern. Two implementors are named in the proposal. Recommendation I recommend acceptance. This proposal is relatively simple, will lead to a nice quality-of-life improvement, is future-compatible (*) with or-patterns that do bind variables/contexts/existentials, and has a natural reading to users unfamiliar with the extension. (*): I suppose that the fact that an or-pattern discards equalities might mean that a later improvement that retains these equalities might interfere with type inference (because in-scope equalities cause type variables to become untouchable). But I will choose not to worry about this. The downsides are: - Yet another feature to think about, including a new extension name. - Yet another feature to implement and maintain. I think the improvements to the language are worth these downsides, though I could be convinced otherwise. Please let me know what you think about this proposal. I'm hoping to accept this proposal in three weeks (a bit longer than my usual timeframe, due to it being a popular time for holidays), unless there is objection. Thanks! Richard

5 5

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 06 Oct '22

06 Oct '22

Dear Haskell community, the GHC Steering committee is seeking nominations for one or more new members. The committee scrutinizes, nitpicks, improves, weighs and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. In particular, please have a look at the bylaws at https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to maintain in perpetuity in GHC's code base, to learn, and to deal with its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore seek a balance of background, expertise, and views on the committee. Membership of the committee gives you the chance to influence the future direction of Haskell, and to serve the Haskell community. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. To nominate yourself, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until February 11th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Call for nominations coming up
by Joachim Breitner 03 Oct '22

03 Oct '22

Dear Committee, with Baldurs resignation, we now have 8 non-expiring member (Arnaud’s term has expired in July) and we ought to do a new call for nominations. Arnaud is of course very welcome to re-nominate himself, and I personally hope he will. Do you have any suggestions for improvements to the process? This is the mail I sent around last time – do you want to to change anything there? https://mail.haskell.org/pipermail/ghc-steering-committee/2022-January/0027… Should I maybe remove the paragraph asking for “conservative members”? Also maybe think of people you’d personally like to nudge to apply. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1