- ghc-steering-committee

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

Stepping down for now
by Cale Gibbard 10 Jul '21

10 Jul '21

I've been having trouble finding time and energy to keep track of GHC steering committee stuff of late, so it's probably best if my place was assigned to someone else. I'll still be around of course, given that my work with Obsidian has me doing GHC development right now, but it's hard to do that, and then also find spare time for this. Thanks! - Cale

2 1

GHC Steering Committee Status
by Joachim Breitner 01 Jul '21

01 Jul '21

Dear Committee, I had some busy months, so this status update is a bit later than expected… but you were all reasonably busy without me, so that’s fine. Over the summer I’ll be away from a laptop for a few weeks, so more than usually please keep tabs on your open tasks, and listen to Tom's nudges. So here’s the delta since May 17th. * Simon suggests a better way to keep tabs on what’s going on. Please join the that discussion! * Iavor left the committee. 👋 * we were asked to review these proposals: #351: NoIncomplete, Shepherd: Vitaly #281: Visible 'forall' in terms, Shepherd: Richard #390: Fine-grained pragmas, Shepherd: Vitaly (back from revision) * we have a recommendation from the shepherd about: #409: Exportable named defaults (partial accept) #283: Local modules (again) (accept) #351: NoIncomplete (accept) #281: Visible "forall" in terms (accept) #412: Explicit Splice Imports (accept) * we have sent the following proposals back to revision #400: Constrained COMPLETE sets (but it’s back already) * we decided about the following proposals #378: support the design for dependent types (accept) We currently have to act on the following 9 proposals, up by 1. ## Waiting for committee decision #281: Visible 'forall' in types of terms, Shepherd: Richard Richard recommends to accep this. It kicked off a discussion about points that one could argue have been covered by #378 already. Conversation has stalled since a month. Simon M, Richard, can you make progress on your conversation? #283: Local modules, Shepherd: Arnaud Arnaud recommends to accepts, and wants more opinions. Please give it! #302: Lambda expressions with guards and multiple clauses, Shepherd: SPJ Committee is preparing a vote #351: NoIncomplete, Shepherd: Vitaly Looks like it’s going to be rejected, since people are partial to -Wpartial instead. Waiting for the author to concur. #392: Clarify modifiers design principle (Shepherd: Alejandro) One comment only so far, please add more. #409: Exportable named defaults, Shepherd: Eric Deliberations about import behavior is going on. #412: splice imports, Shepherd: Vladislav Positive feedback so far. Shall we accept it, Vladislav? ## Waiting for Shepherd action #390: Fine-grained pragmas, Shepherd: Vitaly Vitaly, this is back from revision. What do you think about it? #400: Constrained COMPLETE sets, Shepherd: Vladislav Waiting for recommendation. Vladislav, the author says they addressed your concerns, and it’s now again in your court. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Proposal #302: `\of`
by Richard Eisenberg 01 Jul '21

01 Jul '21

Hi all, Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves. PR: https://github.com/ghc-proposals/ghc-proposals/pull/302 Proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-… Cale's recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075… The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea: mplus :: Maybe Int -> Maybe Int -> Maybe Int mplus = \of Nothing _ -> Nothing _ Nothing -> Nothing (Just x) (Just y) -> Just (x + y) The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual. I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time. Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax. Richard

10 29

#351: NoIncomplete, rec: accept
by Vitaly Bragilevsky 11 Jun '21

11 Jun '21

Dear Committee, We have been discussing the NoIncomplete pragma proposal by John Ericson for quite a long time. I think it's ready for acceptance. The proposal itself: https://github.com/ghc-proposals/ghc-proposals/pull/351 The rendered version: https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness… The proposal aims to introduce the NoIncomplete pragma that would prohibit programs which have a source of incompleteness (in patterns, in methods) in them. There is also the new -fdefer-incompleteness-errors flag. I think this feature comes quite handy in education. I'd use it all the time with my students. Please comment here or in the GitHub thread if you see any problems with this proposal. Vitaly

5 4