November 2022 - ghc-steering-committee

Please review #512: NoFieldSelectors as datatype annotation, Shepherd: Baldur
by Joachim Breitner 03 Mar '23

03 Mar '23

Dear Committee, NoFieldSelectors as datatype annotation have been proposed by Matt Parsons https://github.com/ghc-proposals/ghc-proposals/pull/512 https://github.com/parsonsmatt/ghc-proposals/blob/matt/field-selectors-scop… I suggest Baldur to shepherd this proposal. 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 29

Fwd: GHC2023
by Simon Peyton Jones 20 Jan '23

20 Jan '23

Dear Ghc-Steering-Committee, Here's an email from Tom Ellis about the GHC20xx thread. Please do read it. (Who, if anyone, is the moderator of the ghc-steering-committee mailing list?) Simon ---------- Forwarded message --------- From: Tom Ellis <tom-2019(a)jaguarpaw.co.uk> Date: Tue, 8 Nov 2022 at 08:04 Subject: Re: [ghc-steering-committee] GHC2023 To: Simon Peyton Jones <simon.peytonjones(a)gmail.com> Hello Simon, I sent this to the steering committee mailing list on Saturday but received an email in response saying it was "being held until the list moderator can review it for approval". Perhaps no moderator has had the chance to review it yet, as it hasn't yet appeared on the mailing list archive https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/thr… Perhaps you would be kind enough to forward it to the list for me directly. Thanks, Tom Thanks Simon. On reflection, I'm not particularly motivated to consult the community because the concerns I have impinge most strongly on members of the community who are distant from where a consultation could easily reach, and on non-but-potential-members of the community who are getting a false impression from afar. I will content myself with elaborating on my concerns and then leaving it to the steering committee to take them into account if they see fit. To set the scene, everything I write below is presented from the point of view of someone who wishes Haskell usage to increase and believes that we can't increase Haskell usage by appealing to people who are already comfortable with the way the Haskell ecosystem currently works: we've already got most of those people. For the ten years that I have been in the community, Haskell has had a (false) reputation, to outsiders, as a fragmented language with multiple mysterious things called "language extensions" each of which fractures the language in an incompatible way. "It's impossible to learn Haskell because there are so many incompatible Haskells" they say. It may be hard to believe that this perception exists: as users of GHC we know that there are very few extensions that introduce any incompatibility with others; extensions typically just remove unneccesary restrictions. But, for those of you who don't spend far-too-much of your time on discussion fora such as Hacker News and Reddit, I can guarantee to you that this objection to Haskell comes up *a lot*. Haskell also has, to both insiders and outsiders, a (true) reputation for being an unstable moving target. "It's impossible to learn or use Haskell because the language and libraries keep changing", they say. This one is easier to believe. GHC2021 is a wonderful way of dealing with all of the first and part of the second objection! I can now respond to complaints of language fragmentation and language instability by simply saying "Turn on GHC2021 and be happy". This is great news! (GHC2021 doesn't deal with instability in libraries of course, but I'm pleased that there are many people making efforts in that area too.) I am concerned that GHC2023 would weaken the power of my rejoinder "Turn on GHC2021 and be happy". Now I am at risk of the responses "But why not GHC2023?", "Haskell introduced a new, incompatible language just two years after standardising on GHC2021", "I just spent my precious time learning GHC2021, now I have to spend time learning GHC2023.". Sure, these responses are based on misunderstandings of the technical details. But perceptions really, really matter! If we want a large increase in Haskell usage then we have to take perceptions into account. We can't substantially increase Haskell usage any more by appealing just to our techncial excellence. If we choose to prioritise business-as-usual, that is, the incorporation of highly technically excellent features on a regular basis, with no thought to the costs, then the consequence will be Haskellers-as-usual: people who value that kind of thing in spite of the costs. We already have most of those people. We can't increase Haskell adoption that way. If we choose to change tack then we have the chance of changing the types of people we pick up as new Haskellers, from among those who would never otherwise have considered the language. To put it pithily, Joachim writes in a sibling thread "The point of the GHC20xx series is to get (proven, useful, uncontroversial) goodies into the hands of our users". Are members of the Haskell community, and indeed non-but-potential-members, screaming out for new "goodies"? Or are they screaming out for a brief respite from the unforgiving churn of the Haskell ecosystem, both real and not-real-but-perceived. My experience of the last ten years tells me it's the latter. To be clear, I personally am very much looking forward to more highly technically excellent features, including the exciting ongoing work on dependent types, WASM, GHCJS, and so on. It's one of the aspects of the community that really inspires and excites me! I personally can tolerate the churn. But I don't want those things at the *cost* of continuing to push away potential new users who are currently peering over the fence, discouraged because they can't tolerate the churn that they see, real or perceived. Now, with my stability hat on, looking from the point of view of process design, it's actually *better* for changes to happen in small increments, so maybe having GHC20xx every year is actually *better* than every five years. I don't wish to advocate for one choice or another. Rather I wish to advocate for the point of view that: Technical excellence matters. Stability and the perception of stability matter too. Tom On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <simon.peytonjones(a)gmail.com> wrote: > 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. >> > > Indeed, we originally said we'd review GHC20xx annually, but I think we > might want to consult the community to see if that is too often. There has > been an interesting thread > <https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell > Discourse. > > The HF Stability Working Group discussed this on Monday, and I think Tom > Ellis (a member of the SWG) is willing to lead a consultation. I think > that would be great -- we have no axe to grind here, and I think we'll be > delighted to do whatever makes the maximal number of people happy. > > Tom (cc'd) will write with more info shortly. Sound OK? > > Simon > > On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <mail(a)joachim-breitner.de> > wrote: > >> 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…)

6 21

#511 Deep Subsumption, recommendation: accept
by Spiwack, Arnaud 02 Jan '23

02 Jan '23

Dear all, The Deep Subsumption proposal [ https://github.com/ghc-proposals/ghc-proposals/pull/511 ] proposes a new extension, -XDeepSubsumption, which, when activated, partially reverts the changes from the Simplified Subsumption proposal. The Simplified Subsumption breaks more programs than anticipated. Many don't see any benefit from Simplified Subsumption, just the breakage, and don't like the eta-expansion that it forces. -XDeepSubsumption, when activated, restores deep skolemisation and co/contra-variance of the function arrow (but not deep instantiation, which doesn't affect the observed breakage). The patch already exists for it, and is about 400loc. There are two interesting highlights for me. - It is proposed that -XDeepSubsumption is activated by default in Haskell98 and Haskell2010, but not GHC2021. -XDeepSubsumption is orthogonal to Haskell2010, as far as I can tell, but it gives a cut-off point from which the recommended behaviour (-XNoDeepSubsumption) is the default. - Even with -XDeepSubsumption, the Quick Look algorithm assumes that the function arrow is invariant. The consequences of that are difficult to anticipate, but there is no known example of a bad behaviour due to that interaction yet. The authors also have one unresolved question that I'm bringing to the committee's attention: should `-XDeepSubsumption` be backported to GHC 9.2? --- Despite the fact that this extension is decidedly fork-like, and that it's a real possibility to see the community split around this (after all, the motivation for -XDeepSubsumption is a few libraries which were designed to leverage GHC's deep subsumption, and may very well stay that way in the foreseeable future). I recommend acceptance. Providing a path to backward compatibility seems to me like the right thing to do. I also recommend backporting to GHC 9.2. It should essentially be backward compatible, and providing an update path that doesn't go directly from 9.0 to 9.4 feels better to me.

5 8

#512: NoFieldSelectors as datatype annotation, Recommendation: reject
by Vladislav Zavialov 22 Dec '22

22 Dec '22

Dear Committee, Matt Parsons has proposed #512 "NoFieldSelectors as datatype annotation". Read it here: https://github.com/parsonsmatt/ghc-proposals/blob/matt/field-selectors-scop… Background: An older (accepted and implemented) GHC Proposal #160 "NoFieldSelectors" introduced a language extension flag to control whether top-level field selectors for record data types are generated. That is, when the programmer writes data R = MkR { fld :: Int }, shall we generate a top-level fld :: R -> Int or not? The answer in #160 is to make this controlled by the "FieldSelectors" language extension (enabled by default). Proposal Summary: In the new GHC Proposal #512, Matt argues that the control provided by the language extension introduced in #160 is insufficiently fine-grained, since it applies per-module, not per-definition. Matt has a use case where declarations are generated by Template Haskell and he would like to disable generation of field selectors for the generated declarations. The proposal introduces a new pragma-based annotation to declarations: data {-# NoFieldSelectors #-} R = MkR { fld :: Int } The proposal also introduces constructor-level and field-level annotations: data R = {-# NoFieldSelectors #-} MkR { fld :: Int } data R = MkR { fld :: {-# NoFieldSelectors #-} Int } Recommendation: I recommend rejecting this proposal on multiple grounds. 1. The first reason is the implementation (and maintenance) cost. GHC lacks generic infrastructure for pragmas, so every additional pragma means that we add at least the following: * special support in the parser (and the lexer) * data structures to represent it in the AST, together with TTG extension fields * data structures in the Template Haskell AST and the corresponding conversion logic between TH and GHC ASTs Maybe more, this is off the top of my head. And the proposal introduces not one but three places where a new pragma is allowed. This complexity needs to be justified. 2. The second reason is the existence of a more compelling alternative. I mentioned the lack of generic infrastructure for pragmas, but we do have an accepted proposal for generic annotations: it's #370 "Syntax for Modifiers". If the proposal switched to syntax introduced in #370, it would address the first objection. However, the author is unwilling to do so as long as #370 is not implemented (even though it's an accepted proposal). The author argues that we could switch to the modifiers syntax in the future, but it does not actually address my concern: if we get the pragma syntax, it's going to stay with us forever (that is how things typically work in GHC), and supporting *both* the pragma and modifiers would be worse still. 3. The third reason is ideological. Pragmas are syntactically similar to comments because (ideally) one should be able to ignore them. We use them to define rewrite rules, to mark fields unpacked, or to add cost centre annotations, because it only affects the performance/profiling, not the semantics of the code. But here, a pragma would affect what names are brought into scope, and as such, it shouldn't really be a pragma (syntactically). 4. The fourth reason is that an easy workaround is available. Just move declarations into a separate module with "NoFieldSelectors". I understand that it might be unsatisfactory and inconvenient, but it works and I'm weighing it against the maintenance cost mentioned in (1). To summarize, I'm not thrilled about adding a feature that (1) imposes maintenance costs on GHC, (2) could be done better, (3) uses inappropriate syntax, and (4) has a readily available workaround. I recognize the author's motivation but I believe their use case can be addressed in a more principled way using #370 Modifiers. Let me know what you think. Discussion period: 2 weeks. - Vlad

6 17

#451: WARNING pragma with category, Recommendation: accept
by Joachim Breitner 21 Dec '22

21 Dec '22

Dear all, Adam has submitted “WARNING pragmas with categories” for committee consideration: https://github.com/ghc-proposals/ghc-proposals/pull/541 https://github.com/adamgundry/ghc-proposals/blob/warning-pragmas/proposals/… I’m shepherding that one myself. WARNING pragmas can come with categories now: {-# WARNING [partial] head "This is a partial function, …" #-} so that one can sensible group them and allow the user to silence the warning (-Wno-x-partial) or make them errors (-Werror-x-partial), just like with the built-in warning categories. No language pragma is required (presumably since we are already in a GHC-specific pragma). These custom warnings categories need to be prefixed with `x-` on the command line to keep them separate from the built-in warnings. This is a decision where I am inviting the committee to bikeshed: * Do we really need a separator, or is it ok for library-defined warnings to join a built-in category? * Should it be used in syntax as well (WARNING [x-partial]) for easier predictability and later extension to other prefixes (see below)? All these custom warning categories are part of the severity group -Wdefault (on by default, not errors). I expect we eventually want to give the programmer control over the severity (off by default, error by default, part of -Wcompat, etc…), but it’s not immediately clear what to do here, so we can add it latter (another optional field in the pragma, a separate pragma, a naming convention like xe-foo, or something else). Please complain if you think this needs to be addressed here. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 11

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 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