July 2021 - ghc-steering-committee

Please review #392: Clarify modifiers design principle, Shepherd: Alejandro
by Joachim Breitner 28 Jan '22

28 Jan '22

Dear Committe, Clarify modifiers design principle has been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/392 This is an amendmend to #370, see the PR description for links to diffs etc. I propose Alejandro as the shepherd, as he shepherded #370 before. 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/

4 14

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

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

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

18 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 #409: Exportable named defaults, Shepherd: Eric
by Joachim Breitner 30 Sep '21

30 Sep '21

Dear Committe, Exportable named defaults has been proposed by Mario https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/blamario/ghc-proposals/blob/exportable-named-default/pro… I propose Eric as the Shepherd. This did not gather a lot of attention on Github, or rather none, so Eric, maybe also consider whether this needs to be advertised more, or maybe who should be pointed to 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/

7 36

Proposal #302: Multiway lambda: time to vote
by Simon Peyton Jones 21 Sep '21

21 Sep '21

Friends Sorry to be slow on #302: multi-way lambda. I was diverted by the POPL deadline. I have not heard from Tom or Vitaly, I think, but I'll take silence for agreement with the ballot list. So it is time to vote! Please go here<https://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAI…>, and vote. Feel free to add pros/cons to the list on that page. Please vote by next Thursday, 22 July, at the latest. It's a balance of judgement, for sure, not technically complicated. Simon From: Simon Peyton Jones <simonpj(a)microsoft.com> Sent: 28 June 2021 10:45 To: ghc-steering-committee(a)haskell.org Cc: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: RE: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) Dear Steering Committee Two weeks ago I asked * Are there any other alternatives you strongly want on the ballot? I got these responses * Joachim, Simon, Alejandro, Arnaud: nothing to add * Vitaly, Eric, Tom, Richard, Vlad: no response I'd love to hear from the five of you, please. I want to get a decision on this, and I can't do that if I don't hear from you. Thanks Simon From: ghc-steering-committee <ghc-steering-committee-bounces(a)haskell.org<mailto:ghc-steering-committee-bounces@haskell.org>> On Behalf Of Simon Peyton Jones via ghc-steering-committee Sent: 15 June 2021 13:52 To: Joachim Breitner <mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de>>; ghc-steering-committee(a)haskell.org<mailto:ghc-steering-committee@haskell.org> Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) | I'd like to reassing shepherding of this one. | | It seems to be clear that we want "something like this", there are many ways | to skin the cat, so it comes down to opinion and what we need is a decision | (or a call to votes). As with anything that's possibly quite opinionated, | it's good to have an authorative voice, so in this case, Simon PJ. | | Simon, can you either come up with a "all things considered, I think this | variant is the (narrowly) the best" recommendation or, alternative, a | "please vote on the following options" verdict? OK, to remind everyone * Here is the proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> * Here is the discussion: https://github.com/ghc-proposals/ghc-proposals/pull/302<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> The basic idea is to extend to lambda all the facilities that you get with function definitions, especially multiple patterns and guards. This seems clearly a good idea, whose only obstacle is syntactic. There are no conceptual or specification challenges. The only point at issue is that of concrete syntax. The proposal offers four possible syntactic options. After reviewing, I propose to discard (2) and (3) leaving these alternatives * Option (1) \cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } * Lives alongside \case, but allows multiple patterns * Other keywords are possible, but I think it must be a variant on \case * Option (4) Same, but use \case as the keyword * Incompatible with existing \case => extended transition period, unhappy users * \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens forever, which in the common case of a one argument lambda see clunky. * Option (X). Reject the proposal. Personally I favour (1). I'm relaxed about having multiple ways of saying the thing (think of let vs where), and I see no harm provided the two constructs look and behave the same. I've decided I like \cases precisely because it's the plural of \case, which is exactly what is going on. I think we'll end up having to vote on this, which is fine when it's a judgement call about syntax. But first: * Are there any other alternatives you strongly want on the ballot? I say "strongly" because I don't want to open up a big new debate... we at the stage of trying to narrow options. Thanks Simon

9 22

#390: Fine-grained pragmas, recommendation: accept
by Vitaly Bragilevsky 18 Sep '21

18 Sep '21

Dear Committee, Our own Alejandro has been proposed Fine-grained pragmas for classes, families, and instances https://github.com/ghc-proposals/ghc-proposals/pull/390 https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/000… His idea is to bring the flexibility of overlaps/overlapping/overlappable pragmas to termination checking, type inference, and constraint solving. Alejandro proposes to introduce the following %-modifiers (as in already accepted #370, https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-m… ): %NoTerminationCheck %LiberalCoverage %LiberalInjectivity %Overlapping %Overlappable %Overlaps to liberate conditions for classes and instances, type families, forall-types, etc. The first three modifiers can be used instead of the scary-sounding UndecidableInstances extension. The last three modifiers are supposed to be used instead of the overlap*-pragmas for instances we already have. Note that this proposal doesn't suggest deprecating those extensions and pragmas. I think that this proposal goes in the right direction and recommend accepting it. As far as I understand, all the committee members, including those with terms about to expire, have the right to either support this proposal or to raise a voice against it either here or at https://github.com/ghc-proposals/ghc-proposals/pull/390. Regards, Vitaly

5 7

Proposal #412: Explicit Splice Imports; rec: accept
by Vladislav Zavialov (int-index) 14 Sep '21

14 Sep '21

Dear Committee, Proposal #412 "Explicit Splice Imports” by Matthew Pickering has been submitted for our consideration. Read it here: https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/0… Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/412 The goals of this proposal are to (1) improve parallel compilation, (2) speed up -fno-code and IDEs that rely on it, (3) reduce binary sizes or at least reduce linking overhead, (4) create phase separation useful for cross-compilation. All of the above are achieved by introducing a new form of import called a splice-import. Compare: import M import splice H Under this proposal, names imported from M can *not* be used in top-level Template Haskell splices, whereas names imported from H can be used *only* in Template Haskell splices. At this point I will note that I do not particularly like the proposed syntax, which looks as if we’re importing a splice rather than importing names for use in splices. In the “Alternatives” section, you will find several other options such as “import {-# SPLICE #-} M”, “import for splice H”, “$(import H)”, and so on. That said, let us not get bogged down in the discussion of syntax before we agree on the semantics. If we choose to accept the proposal, I will organize a vote on the syntax. Regarding the semantics, I believe the general idea behind the proposal is good, and I recommend acceptance. It provides a way for the programmer to specify the intended usage of an import (whether it is for normal programming or metaprogramming), and GHC can use this information to build the program more effectively (more parallelism, less linking). In ways that I do not entirely understand, it is allegedly good for future work on cross-compilation. Let me know what you think. - Vlad

6 6

Please review #400: Constrained COMPLETE sets, Shepherd: Cale
by Joachim Breitner 14 Sep '21

14 Sep '21

Dear Committee, this is your secretary speaking: Constrained COMPLETE sets has been proposed by Sebastian Graph https://github.com/ghc-proposals/ghc-proposals/pull/400 https://github.com/sgraf812/ghc-proposals/blob/constrained-complete-sigs/pr… This proposal tries to solve the same issue as Cale’s #399, and essentially has slightly different syntax. I therefore suggest that Cale is the shepherd, and hashes out with Sebastian the details of syntax so that they can both get behind it, and then makes a recommendation. 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 3

Scoping of types
by Alejandro Serrano Mena 15 Aug '21

15 Aug '21

Dear Committee, There’s a lot happening right now in the GHC proposals repo about scoping of types in different elements in the language. Richard asked for our decision in #238, but following a very good suggestion from Joachim, I think it’s better to give an overview on what’s going on. In my opinion, this should lead to a consolidation of the different proposals into a unified design. *Current status* In Haskell 2010 there’s no way to refer to type variables introduced in a type signature. For a long time, GHC has shipped with -XScopedTypeVariables, which introduced scoping for types by prepending them with `forall`. We could then use it in other types, or as part of a type application if -XTypeApplications is on. > id :: forall a. a -> a > id x = f @a x > where f y = y In the past 3 years we’ve accepted two proposals which extend this ability: - First to patterns https://github.com/ghc-proposals/ghc-proposals/pull/126, so we can write `id @a x = …` - Then to lambdas https://github.com/ghc-proposals/ghc-proposals/pull/155, so we can write `id = \@a x -> …` *What is going on* It seems that the accepted proposals were not quite right. We have two on-going proposals to *amend* the current ones: - https://github.com/ghc-proposals/ghc-proposals/pull/291 proposes simplifications to type variable patterns. As I understand this would make type variables in patterns behave like term variables (cannot be repeated, occurrences in inner scopes shadow the outer one, and so on). - https://github.com/ghc-proposals/ghc-proposals/pull/238 introduces -XTypeAbstractions, which make the combination of `forall` and `\@a` behave “as it should be”. But to be honest, I do not fully grasp the problems before, so neither how this amendment solves the problem; there’s a pointer to the GHC issue tracker where some incompatibility is discussed https://gitlab.haskell.org/ghc/ghc/-/issues/16734#note_203412 - https://github.com/ghc-proposals/ghc-proposals/pull/420 amends the current behaviour of signatures in patterns (what happens if I write `id (x :: a)` ). So we have different ways to introduce new type variables: `f :: forall a. …`, `f @a = …`, `f = \@a -> …`, `f (x :: a) = …`; and it’s very unclear what the scoping mechanism for each one should be. I think the problem is characterised very well in the following comment by Simon PJ https://github.com/ghc-proposals/ghc-proposals/pull/291#issuecomment-726715… Note that this problem is arising in other places, too. For example #281, which adds visible `forall a -> ` ( https://github.com/ghc-proposals/ghc-proposals/pull/281) is also talking about name resolution (see https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-884810… for an example). *How should we proceed* Personally, I am a bit worried about having divergent designs on this matter, and the fact that no fewer than 2 amendments are being proposed (!) For me, the best would be to come up with a unified design of how scoping works for types, covering all possible ways to introduce and resolve them. I am happy to help with this. Another important point seems to be how far we want to get from the current status quo (-XScopedTypeVariables make a type variable in a signature scope in its body, type variables in pattern signatures are always fresh), and how that fits with the overall -XDependentHaskell initiative. Kind regards, Alejandro

5 7