- ghc-steering-committee

#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

GHC Steering Committee Status
by Joachim Breitner 14 Sep '21

14 Sep '21

Dear Committee, I hope you all had a lovely summer, an interesting ICFP and Haskell Love and other conferences, and are slowly moving back into action. What has happened since the last status (on July 1st)? * Simon suggested a better way to keep tabs on what’s going on. I’ll try to keep https://github.com/ghc-proposals/ghc-proposals/wiki/Status as up to date as the latest status email. I ran out of time today, so I did not yet try to make the format tabular and prettier. Sorry, next time! But I added a time stamp to each that roughly corresponds to the latest state change. * Cale has stepped down. Thanks for your contributions! * we were asked to review these proposals: #319: NoFallibleDo proposal (resubmission) #425: Invisible binders in type declarations, Shepherd: Richard * we have a recommendation from the shepherd about: #390: Fine-grained pragmas (accept) #319: NoFallibleDo proposal (reject) * we have sent the following proposals back to revision #390: Fine-grained pragmas #315: NoIncomplete (author wants to revisit) * we decided about the following proposals none this round? We currently have to act on the following 9 proposals, same as last round. ## Waiting for committee decision #281: Visible 'forall' in types of terms, Shepherd: Richard 2021-07-19: After still some more discussion, Richard again recommends to accept this, answering Simon M’s questions. Simon, are you fine with that? #283: Local modules, Shepherd: Arnaud 2021-05-20: Arnaud recommends to accepts, and wants more opinions. Opinions still sparse. Please give it! #302: Lambda expressions with guards and multiple clauses, Shepherd: SPJ 2021-07-29: Vote done, one open question about pragma design. #319: NoFallibleDo, Shepherd: Alejandro 2021-07-23: Rejection recommended Committee comments please? #392: Clarify modifiers design principle (Shepherd: Alejandro) 2021-07-23: Alejandro asked for more eyes. Discussion about grammar and compatibility with #390 open #409: Exportable named defaults, Shepherd: Eric 2021-09-10: SPJ wants to have a last look, reminder is set #412: splice imports, Shepherd: Vladislav 2021-06-24: Acceptance recommended Positive feedback so far, but more discussion Shall we accept it, Vladislav? ## Waiting for Shepherd action #400: Constrained COMPLETE sets, Shepherd: Vladislav 2021-06-22: Waiting for recommendation. Vladislav, time to get active! #425: Invisible binders in type declarations, Shepherd: Richard 2021-08-13: Waiting for recommendation. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

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

Unlifted data types
by Simon Peyton Jones 19 Aug '21

19 Aug '21

I have just posted<https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-896626…> this, about unlifted data types. Yikes! Simon In accepted proposal #265 on Unlifted Datatypes<https://github.com/ghc-proposals/ghc-proposals/pull/265> I have just realised that in this accepted, and implemented proposal we have done something entirely new. Consider this (from https://gitlab.haskell.org/ghc/ghc/-/issues/20204) type IntU :: Bool -> Wombat ...LOTS OF CODE... data IntU a b = IntU Int ...MORE CODE... type Wombat =Type -> TYPE UnliftedRep The kind signature for IntU completely changes the semantics of the data IntU declaration, and yet can be separate from it. That is new: generally, signatures can restrict the applicability of something, but don't change its semantics. (Yes, with overlapping instances, certainly incoherent instances, you could change semantics, but the general principal holds.) Even if it is adjacent, the fact that it's unlifted is quite subtle... you have to look to the right of the arrows, and then through the distant (and perhaps imported) type synonym Wombat. I'm not very happy with a distant kind signature having such a profound effect on the semantics of the data type. Indeed in my comment above<https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-525705…> I suggested a keyword data unlifted IntU a b = IntU Int to signal that it's an unlifted data type. But then I went AWOL and didn't pursue the matter. I don't know why I was so negligent. So this post is to ask: does anyone else think this is bizarre? I'm inclined to make a proposal to add the keyword, but I thought I'd test the waters first.

4 7

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

Please review #425: Invisible binders in type declarations, Shepherd: Richard
by Joachim Breitner 14 Aug '21

14 Aug '21

Dear Committee, this is your secretary speaking: Invisible binders in type declarations has been proposed by Vladislav https://github.com/ghc-proposals/ghc-proposals/pull/425 https://github.com/serokell/ghc-proposals/blob/decl-invis-binders/proposals… I propose Richard as the shepherd, simply because he already scrutinized the proposal on Github. Maybe that is a bit unfair: One could find it unfair towards other committee members that they get fewer proposals assigned. Or unfair towards Richard that he gets penalized for engaging with the community. Up to your point of view. Best way to fix that would be if more committee members are actively engaging with proposals even before they are being submitted. 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

\cases
by Simon Peyton Jones 29 Jul '21

29 Jul '21

Folks I've had a final thought about \cases. Looking at it now, I wonder if we can simply expand what LambdaCase allows, rather than having yet another extension. That is, LambdaCase now accepts \cases as well as \case. If we'd designed it from scratch we certainly would not have had two different extensions. The only downside I can see is a loss of back-compat in this program {-# LANGUAGE LambdaCase #-} module Foo where f = \cases -> cases + 1 -- Adds 1 g = \case { True -> False, False -> True } If we extend what LambdaCase does, the definition of f will change its meaning. But this is so bizarre that I'm disinclined to waste time on it. My suggestion: expand what LambdaCase does. If not, the new extension should be LambdaCases. Can you reply on the GitHub? https://github.com/ghc-proposals/ghc-proposals/pull/302 Simon

2 1

#302 \cases
by Simon Peyton Jones 27 Jul '21

27 Jul '21

Dear steering committee, See below - it seems that (1) is the winner. I have recorded the results on our document here<https://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAI…>. I'll post on the GitHub. Thanks for participating in this. I think this ranked-preference voting works well when it comes down to a balance of taste on syntax, so that complete unanimity is unreasonable expectation. Simon From: Joachim Breitner <mail(a)joachim-breitner.de> Sent: 26 July 2021 21:19 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: Running the voting algorithm I'll do it by hand: Votes: 1 > X > 2 = 4 2 > 4 > X > 1 1 > 4 > 2 > X 1 > X > 2 = 4 2 > 1 > X > 4 X > 1 > 2 = 4 1 > X > 2 = 4 1 > 2 > X > 4 1 > X > 2 = 4 2 > X > 1 > 4 Let's see if 1 is the winner: 1 beats 2 by 7 vs. 3 votes 1 beats 4 by 9 vs. 1 votes 1 beats X by 7 vs. 3 votes The winner is 1. (This tally was created on the phone in a tent on a mountain above a Norwegian fjord.) 26.07.2021 13:31:36 Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>>: Joachim We have votes for \case, here https://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAI…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goog…> Could you possibly run the voting algorithm - or tell me how to? Thanks Simon

1 0

GHC proposals
by Simon Peyton Jones 12 Jul '21

12 Jul '21

Friends I'm a bit concerned that we are falling down on our commitment to decide about GHC proposals in a timely manner. Part of the problem is that at any moment I don't have a clear snapshot in my head of what decisions are pending, and who is driving them. I know that Joachim hates manual solutions, but I have spent a few minutes digging through my email to build * this spreadsheet giving the current status<https://docs.google.com/spreadsheets/d/1tt2BUtr6ws4YtdkM7f986pb8rid26-TyKxs…> You all have edit permissions. It covers only the handful of proposals that are in our court. Can I suggest that we all use it to keep ourselves on the ball? E.g. as a shepherd you can use it to record who you are waiting for, as I have done for #302. You'll notice that we are behind on every one of them. Remember, if there edits we want the author to make, we push it back, out of our court. It can re-enter when the author re-submits. If our commitments are over-ambitious, let's review them. Tom: you are our official nudger. Would you like to make you weekly nudge into an email to the full committee, with a pointer to the spreadsheet and your current understanding of who is responsible for driving? I hope this is helpful. If not, let's think of something else! Simon

2 5