- ghc-steering-committee

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

Please review #413: GHC Maintainer Preview, Shepherd: Vlad
by Joachim Breitner 31 Oct '21

31 Oct '21

Dear Committee, this is your secretary speaking: GHC Maintainer Preview, a change to GHC's release process, has been proposed by Hécate Moonlight. https://github.com/ghc-proposals/ghc-proposals/pull/413 https://github.com/Kleidukos/ghc-proposals/blob/patch-1/proposals/0000-ghc-… I propose Vladislav 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/

2 1

#433: the Unsatisfiable constraint; recommendation: accept
by Tom Harding 27 Oct '21

27 Oct '21

Hi all, Firstly, apologies for the radio silence - I’ve apparently been having some undiscovered email trouble (perhaps even since joining the committee), and so I’m now going to be using my usual, and hopefully far more reliable, email address. With that said, I’d like to recommend proposal #433 <https://github.com/ghc-proposals/ghc-proposals/pull/433> for acceptance. The proposal does a good job of outlining the difference between this and the current TypeError mechanism, and I think the case is well justified. Certainly, the ability to bypass fundep checks in error case “instances” immediately brought to mind a handful of places in my own libraries that could benefit from this check. I think the thread already contains a lot of committee activity, but I welcome any further comments! Thanks, Tom

4 3

#283: Local modules (again), recommendation: accept
by Spiwack, Arnaud 19 Oct '21

19 Oct '21

Dear all, It is time to review the local modules proposal, from our own Richard Eisenberg, again. In fact it’s been time for a while, and I must apologise to Richard for not having understood that. Sorry, Richard. Link: https://github.com/ghc-proposals/ghc-proposals/pull/283 Since the last time, the proposal has been both simplified and made more precise. The main issues solved by this proposal are - The ability to export qualified names from modules - The ability to define functions with qualified names within a module ( *e.g.* you could have both T.f and U.f). - The ability to locally refer to qualified data as unqualified (suppose Set.map is in scope, then the proposal lets you write let import module Set in map f (map g some_set). I think these are three important issues, and the proposal makes a good case that they ought to be solved together. I also think that the specification is clear and doesn’t leave any dark corner. Caveat: I have contributed to writing the current specification, so I may be missing some flaws. The proposal does introduce a somewhat byzantine semantic difference between module X and module qualified X in export lists. This is to keep the current meaning of module X which is already not very intuitive (cf https://ro-che.info/articles/2012-12-25-haskell-module-system-p1 ). I think this is unavoidable. There are also 3 optional pieces of specification that we are asked to rule on (§4). I’m personally in favour of option 1. I’m weakly in favour of option 3 (with a preference for the variant described in Alternative 7). On the other hand option 2 seems to add a bit too much syntactic subtlety to be worth it (though if we choose option 2, I see no reason not to accept Alternative 3 as well). /Arnaud

8 23

Please review #433: the Unsatisfiable constraint, Shepherd: Tom
by Joachim Breitner 16 Oct '21

16 Oct '21

Dear Committee, this is your secretary speaking: Unsatisfiable has been proposed by Adam Gundry https://github.com/ghc-proposals/ghc-proposals/pull/433 https://github.com/adamgundry/ghc-proposals/blob/unsatisfiable/proposals/00… I propose Tom Harding 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/

1 0