- ghc-steering-committee

Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel
by Joachim Breitner 08 Jan '22

08 Jan '22

Dear Committee, this is your secretary speaking: NoFallibleDo proposal has been proposed by Cale https://github.com/ghc-proposals/ghc-proposals/pull/319 https://github.com/obsidiansystems/ghc-proposals/blob/no-fallible-do/propos… I propose Eric Seidel as the shepherd. 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/

6 18

Please review #448: Modern Scoped Type Variables, Shepherd: Arnaud
by Joachim Breitner 07 Jan '22

07 Jan '22

Dear Committee, this is your secretary speaking: We had a bunch of proposals related to scoping and type variables, and complained about that confusion. Richard built a unified proposal (or he volunteered), which is now up for consideration: https://github.com/ghc-proposals/ghc-proposals/pull/448 https://github.com/goldfirere/ghc-proposals/blob/type-variables/proposals/0… I propose that Arnaud shepherds this. 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/

1 0

Please review #454: custom type warnings Shepherd: Tom
by Joachim Breitner 05 Jan '22

05 Jan '22

Dear Committee, this is your secretary speaking (who is back from travels): Custom type warnings has been proposed by Adam https://github.com/ghc-proposals/ghc-proposals/pull/460 https://github.com/adamgundry/ghc-proposals/blob/custom-type-warnings/propo… This was extracted from #433, so I suggest that Tom shepherds this one too. 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/

1 0

#460: better migration for non-magical ~
by Richard Eisenberg 17 Dec '21

17 Dec '21

Hi all, I am shepherding Proposal #460, an amendment to accepted proposal #371. #371 proposed making the ~ operator completely non-magical in parsing, behaving syntactically like any other operator. It would have to be imported (though it would be exported from the Prelude, so most users get it for free), -XTypeOperators would have to be enabled, and its appearance is unaffected by -XGADTs or -XTypeFamilies. This proposal was approved, but only very weakly: I gave a soft recommendation to accept, which Simon PJ trusted (but without much independent confirmation, it seems), Joachim gave a weak accept, and Alejandro and Arnaud said things mildly against (but did not quite vote for rejection). Text for accepted proposal #371: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0371-n… This current #460 is a small amendment to #371 that makes the migration story gentler. All current programs would continue to be accepted for 8 releases. If ~ is used in a file without TypeOperators, a warning (enabled by default) triggers, saying that the user should enable TypeOperators. This fix is backward compatible. If ~ is used when it is out of scope (say, because a module does not import the Prelude), a warning (in -Wcompat) triggers. The fix is not backward compatible, because (~) is not currently exported from the Prelude. This warning gets moved from -Wcompat to the default warning set after 2 releases. The previous migration story had no warning for a missing -XTypeOperators, meaning that some code would break immediately (although the fix is easy and backward compatible). Text for amended proposal: https://github.com/int-index/ghc-proposals/blob/eqtycon-migration/proposals… Amendment diff: https://github.com/ghc-proposals/ghc-proposals/pull/460/files --- I recommend acceptance, because immediate breakage of code is bad: it causes kinks in the update cycle after a GHC release. This new migration story should be gentler, and poses little implementation burden. Given the minor nature of this proposal, I will accept in one week if there is not dissent. Thanks, Richard

3 2

GHC Steering Committee Status
by Joachim Breitner 15 Dec '21

15 Dec '21

Dear Committee, I hope you all had a lovely fall. Three months since the last status mail! High time for a new one. So what has happened since the last one? * Simon suggested a better way to keep tabs on what’s going on, and you’ll find the second have of this mail at https://github.com/ghc-proposals/ghc-proposals/wiki/Status I still didn’t get around to mess with markdown tables etc… sorry. If someone feels inspired for how that wiki page would look better, ideally with markup that I can easily edit and include in this email, suggestions are welcome. * Alejandro announced to step down once through with his currently shepherded proposals. * We decided to not define GHC2022. * we were asked to review these proposals: #433: the Unsatisfiable constraint #452: Articulate principles for GHC evolution #451: Sized literals proposal #460: migration plan for non-magical-~ * we have a recommendation from the shepherd about: #400: COMPLETE set signatures; rec: accept #425: invisible binders in type declarations; rec: accept #433: the Unsatisfiable constraint; recommendation: accept * we have sent the following proposals back to revision #412: Explicit Splice Imports #400: COMPLETE set signatures #283: Local modules * we decided about the following proposals #302: Multiway lambda (accept) #409: Exportable named defaults (accept) #281: Visible "forall" in terms (accept) #433: the Unsatisfiable constraint; recommendation: accept We currently have to act on the following 6 proposals, down by 3: ## Waiting for committee decision #452: Articulate principles for GHC evolution (Shepherd: SPJ) 2021-12-15: Ongoing discussion, heading for acceptance #425: Invisible binders in type declarations, Shepherd: Richard 2021-10-19: Recommendation to accept #392: Clarify modifiers design principle (Shepherd: Alejandro) 2021-07-23: Alejandro asked for more eyes. Discussion about grammar and compatibility with #390 open Richard posted last. Please follow up! #319: NoFallibleDo, Shepherd: Alejandro 2021-07-23: Rejection recommended Continued silence since the last update. Committee comments please? ## Waiting for Shepherd action #451: Sized Literals, Shepherd: Simon M. 2021-11-19: Assigned to Simon M. Simon, what do you think of this? #460: migration plan for non-magical-~, Shepherd: Richard 2021-12-15: Assigned to Richard Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #460: migration plan for non-magical-~ Shepherd: Richard
by Joachim Breitner 15 Dec '21

15 Dec '21

Dear Committee, this is your secretary speaking (who is back from travels): Vlad proposed an amendment to #371 (Export ~ from Data.Type.Equality) to improve the migration plan https://github.com/ghc-proposals/ghc-proposals/pull/460 Following the tradition that amendments are shepherded by the same shepherd as the original proposal, this falls on Richard. 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/

1 0

#433: the Unsatisfiable constraint; recommendation: accept
by Tom Harding 08 Dec '21

08 Dec '21

Hi all, Since I last emailed the committee, Adam has split the proposal into two parts: one for `Unsatisfiable` and one for `Warning`. I think I’m right in saying that everyone who has voiced an opinion has been in favour of the `Unsatisfiable` half, so if no one has any further thoughts, I suggest we accept this half and continue discussing `Warning` later on. Thanks, Tom

2 2

Local module proposal on hiatus
by Spiwack, Arnaud 22 Nov '21

22 Nov '21

Dear all, Richard has decided to stop working on the local module proposal [ https://github.com/ghc-proposals/ghc-proposals/pull/283#issuecomment-974382… ]. Just as I was about to say that we ought to accept it unless a strong opposition was voiced within the next two weeks. What's left to do, as far as anyone can tell, is address two minor technical points (there may be other corner cases that have been missed: it's an ambitious proposal after all; but it's looking like it's standing on firm ground). I've stated previously that I care a lot about this proposal. Unfortunately, I currently don't have time to take care of the proposal myself. I may revisit this decision in 2022 (which, fortunately, is rather soon), depending on how my schedule changes. But until then, unless someone steps up, I'll mark the proposal as dormant. Best, Arnaud

3 2

Away from a laptop
by Joachim Breitner 10 Nov '21

10 Nov '21

Dear committee, I’ll be away from my laptop for a few weeks from Monday on, and might be slow to do my secretary duties, and some things (like merging a proposal with updating the metadata and possibly converting from .md to .rst) are quite unwieldy to do just on a phone. If something can’t or should not wait, I’d be grateful if others could cover for me. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Proposal #281: Visible "forall" in terms; rec: accept
by Richard Eisenberg 01 Nov '21

01 Nov '21

Hi committee, Proposal #281 has been submitted for our consideration. Proposal PR: https://github.com/ghc-proposals/ghc-proposals/pull/281 <https://github.com/ghc-proposals/ghc-proposals/pull/281> Proposal text: https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00… <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00…> The text of the proposal is long and detailed, but do not be daunted: it is simpler in practice than it appears. The main payload of the proposal is: Introduce a new extension -XRequiredTypeArguments. With this extension enabled, the `forall ... ->` syntax, currently in existence in kinds, is now available in types (of ordinary functions). This means that function definitions and call sites are sometimes required to write a type argument. The type argument is *not* preceded by @ or any other syntactic marker. This is useful for defining what would otherwise be ambiguous types. Example: > sizeof :: forall a -> Sizeable a => Int > sizeof = ... > > intWidth = sizeof Int There are further examples and motivation in the proposal. The rest of the proposal is simply about dealing with odd corner cases that come up with the main payload. In particular, mixing types in with terms with no syntactic signifier means that we must be careful about parsing and namespaces. If a type argument is written in the syntax that is shared between types and terms (including function application!) and uses identifiers in scope in only one of the two namespaces, nothing unusual can be observed. But, of course, there are corner cases. Here are some of the salient details: - Define type-syntax and term-syntax, where the choice of syntax is always driven by syntactic markers, such as :: or @. See the dependent types proposal <https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/…> for more details. Parsing and name-resolution are controlled by whether a phrase is in type-syntax or term-syntax. For name resolution, if a lookup fails in the first namespace (the term-level namespace in term-syntax or the type-level namespace in type-syntax), we try the other namespace before failing. - Because term- vs type-syntax is controlled by syntax, a required type argument is in *term*-syntax and gets name-resolved *as a term*. In the absence of punning, this works out fine, but it is possible that a punned identifier will cause confusion. The proposal includes section 4.3 allowing users to write `type` to signify a switch to type-syntax. - The proposal also includes a way to avoid punning for the built-in types with privileged syntax: lists and tuples. This method allows users to specify -XNoListTupleTypeSyntax to disable the list and tuple syntax in types (but still allows it for terms). The proposal also suggests exporting type List = [] from Data.List and other synonyms for tuples from Data.Tuple. --------------- I recommend acceptance. When doing type-level programming, the lack of this feature is strange, leading to ambiguous types and easy-to-forget arguments and easy-to-make type errors. The design space here is difficult, but this proposal is very much in keeping with the design sketch of our recently-accepted #378, in particular its section on this point <https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/…>. I believe the design described here is both backward compatible with what we have today (users who do not use this feature will not notice a difference) and forward compatible with a cohesive design for dependent types. There are several optional pieces: - The `type` herald <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00…>. I am unsure about this one, but others have felt strongly in favor, and I have no reason to object. - Types-in-terms <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00…>. I think this is necessary in order to avoid annoying definitions of type synonyms for one-off usage sites. It is a straightforward extension of the term-level parser to allow previously type-level-only constructs. It is necessary in order for us to achieve the vision of dependent types in #378. The only challenge here is that this requires us to make `forall` an unconditional keyword in terms. This does pose a backward-compatibility problem. I see, for example, that the sbv package exports a function named `forall`, so we may need to think more carefully about how to proceed here -- possibly by guarding the keyword-ness of `forall` behind the extension for some number of transitionary releases. - Lists and Tuples <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00…>. This section describes the -XNoListTupleTypeSyntax extension. I am not convinced that this change needs to be part of this proposal (thinking it belongs more in #270), but I do think we'll need it in the end. Is it OK to export new type synonyms from Data.List and Data.Tuple? Not sure, though I'd like these exported from some central place. What do others think? Thanks, Richard

7 31