July 2018 - ghc-steering-committee

Bundling patterns with type synonyms (#28)
by Christopher Allen 27 Jan '19

27 Jan '19

The proposal I'm reviewing is: Bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski https://github.com/ghc-proposals/ghc-proposals/pull/28 Having reviewed the proposal and gone through some of the GHC Trac history, I think we should accept this proposal. There are a couple of open questions, ambiguities, and potential downsides but the overall complexity of the proposal doesn't cause me great concern. Cheers, Chris Allen

5 11

Proposal: Syntax for visible dependent quantification (#81)
by Roman Leshchinskiy 30 Sep '18

30 Sep '18

Hi everyone, The proposal is about adding support for dependent quantification to kind signatures: https://github.com/ghc-proposals/ghc-proposals/pull/81 Consider the following declaration (example lifted from the proposal): data T k (a :: k) GHC accepts this but it can't be given an explicit kind. Internally, it is assigned a kind which is rendered as forall k -> k -> * but this isn't accepted in source code. Note that in applications of T, k must be specified explicitly (e.g., T Type Int) which is why T does *not* have the kind forall k. k -> * Moreover, k is mentioned later in the kind which is why something like Type -> k -> * doesn't work, either. The proposal is to allow forall k -> k -> * and similar kinds to appear in source code. This is actually intended as the first in a series of proposals driving us towards dependent types in Haskell as described in Richard's thesis (https://www.cis.upenn.edu/~sweirich/papers/eisenberg-thesis.pdf) Ultimately, the intention is to have all of the following (cf. Chapter 4 of the thesis): forall a. t forall a -> t pi a. t pi a -> t Here, forall and pi express relevance (does it exist at runtime) and . and -> express visibility (does it have to be specified explicitly). Because of this, my recommendation is to strongly encourage the author to submit an extended proposal which reserves (but doesn't specify the semantics of) the above syntax wholesale. This would allow us to ensure that various bits of Dependent Haskell use consistent syntax and language extensions once implemented. I find it quite difficult to discuss just this specific bit of syntax in isolation. Indeed, the public discussion was rather confused without an explanation of the roadmap (https://github.com/ghc-proposals/ghc-proposals/pull/81#issuecomment-3368929…) Alternatively, we could just agree on the roadmap ourselves, without public discussion. This would somewhat circumvent the process, though. If we decide to discuss just the proposal as is, though, then I'd be weakly against the proposed syntax as it is too subtle for my taste and abuses familiar mathematical notation somewhat. I'd probably prefer something like: type a -> t The proposal also doesn't specify what language extension would turn on support for the syntax so this would have to be rectified. Thanks, Roman

4 9

Proposal #111: Linear Types
by Richard Eisenberg 29 Aug '18

29 Aug '18

I have volunteered to shepherd Proposal #111: Linear Types. The pull request is here: https://github.com/ghc-proposals/ghc-proposals/pull/111 The authors propose adding linear functions to GHC. The argument to a linear function must be used exactly once in the function body. Motivation for this feature abounds -- essentially, linear types allow for better static checking around resource allocation and deallocation. I refer you to the proposal (and published paper) for more details here. The proposal also contains multiplicity polymorphism, where a higher-order function can be polymorphic in the multiplicity of a supplied function. Datatypes are linear by default, with a long list of (in my opinion, non-obvious) rules around syntax and exceptions to those rules. Constructors have a different multiplicity when used in an expression than they do when used in a pattern, for example. The authors leave type inference as an open question and do not state how the feature would work with either view patterns or pattern synonyms. The proposal comes with a companion document detailing the changes to Core. These changes seem appropriate. The current proposal has a fair number of open questions. I've written a long comment on the GitHub trail detailing what I was uncertain of. The proposal is not currently near the level of crispness of the proposals we normally accept. For a smaller proposal, I would just send it back to the authors without really giving it to the committee. However, there has been a great deal of effort behind writing this proposal and building an implementation, and so I think it's only fair that we give some thought about the general direction being worked in here. As to the features themselves: I'm personally far from convinced. Though I see no better way to achieve the authors' goals, the feature they have proposed is full of both sharp and dark corners. If implemented, there would be regular questions cropping up as to why such-and-such is the case or why the design is the way it is. However, this is well motivated and eagerly anticipated. And I don't think we'll be able to conjure up a better design without gaining experience with the proposed design, however flawed. I thus recommend: Encouragement to continue the proposal and implementation, with an eye toward acceptance. Furthermore, if/when merged, I would like to advertise that the feature is subject to change, with no backward compatibility guarantee, for several versions. If the feature is implemented and merged, we will learn more about it and then perhaps refine it in the future. Richard

8 25

Discussion about "Type Application in Patterns" (#126)
by Iavor Diatchki 21 Aug '18

21 Aug '18

Hello, let's also start the discussion on feature request 126. The idea here is that we allow the @ notation for explicit type applications to also be used on constructors in patterns. Using @ with a constructor in a pattern has the same meaning as it does it an expression: the provided type is used to instantiate the corresponding type parameter of the constructor. If the type contains variables, those are treated in the same way as in #128, where "unbound" variables name the matching types. Here are some examples: f1 (Just @Int x) = x -- This has type `Maybe Int -> Int` f2 (Just @[a] x) = x == "c" -- `a` is an alias for `Char` f3 (SomeException @e ex) = ... -- `e` is a name for the existentially hidden exception type Overall I think that is a simple and natural extension to the way @ already works, and I propose that we accept it. Thoughts? -Iavor

6 23

Extra Commas (#87), Recommend: accept
by Christopher Allen 06 Aug '18

06 Aug '18

https://github.com/ghc-proposals/ghc-proposals/pull/87 With the provisos mentioned by Simon starting here in mind: https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-3855365… I recommend we accept the proposal with the understanding that the final specification or implementation could be handled by GHC's code review process. I also have a concern about the potential interactions with TupleSections. If no objections are raised, it should be assumed that no one opposes this proposal. --- Chris Allen

7 14

Remove the * kind syntax (#143); Recommendation: accept
by Ben Gamari 04 Aug '18

04 Aug '18

Hi everyone, We are being asked to consider pull request #143. This proposal removes the `*` symbol as a synonym for `Type`, finishing the work started by the new `-XNoStarIsType` extension. This proposal involves a protracted but warranted transition period. In short: 1. `-XNoStarIsType` will be introduced in GHC 8.6 2. Warnings will be introduced in GHC 8.8, increasing in visibility in later releases. 3. `-XStarIsType` will be enabled by default starting 12 releases (roughly 7 years from now) after GHC 8.6. 4. 15 releases (8.5 years from now) after GHC 8.6 `-XNoStarIsType` will be removed. The reason for this breakage is that this change will have wide-spread consequences: in addition to an estimated 25% of Hackage being affected, a generation of written documentation and pedagogical material will need to be revised. While the costs of the change are high, so are the benefits. `*` is an awkward special case in GHC's syntax and is quite hard to search for. Moreover, the `StarIsType` will present a significant hurdle to the future introduction of `DependentHaskell` since `*` may then signify either term-level numeric multiplication or `Type`. For these reasons my recommendation is that we accept the proposal. Cheers, - Ben

3 4

Discussion on "Allow ScopedTypeVariables to refer to types" (#128)
by Iavor Diatchki 04 Aug '18

04 Aug '18

Hello, let's get the discussion going on proposal #128. Summary: this proposal generalizes the behavior of type variables in patterns, specifically the variables that do not refer to an explicitly quantified type parameter. The idea is that such type variables simply introduce a name for their matching type, without placing any restriction on the type. For example, consider the following definition. f (x : [a]) (y : a) = and x This would be accepted and it would have type `[Bool] -> Bool -> Bool`. This proposal is about the meaning of the type signature on `x` which states that it must be a list of something, and `a` will be a name for the type of its elements. In this case, it happens that `a` is actually just an alias for `Bool`. I am strongly in favor of this proposal. As I mentioned on the github discussion, I thought that the feature already worked as in this proposal, and was quite surprised to find out that currently, GHC has restrictions on what `a` could be, and it also complains about "multiple definitions for `a`" in the above example). Thoughts? -Iavor

5 4

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 22 Jul '18

22 Jul '18

Dear Haskell community, the GHC Steering committee is seeking nominations for a new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until July 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Please Review: Type applications in patterns (#126), Shepherd: Iavor again
by Joachim Breitner 17 Jul '18

17 Jul '18

Dear Committee, this is your secretary speaking: Type applications in patterns, by myself and with help from Richard and Simon PJ, was proposed https://github.com/ghc-proposals/ghc-proposals/pull/126 I again propose Iavor as the shepherd. He already has #128 on his plate, and although orthogonal, both touch the same area, both are motivated and explained in more detail in the same paper, so maybe looking at both together is insightful. Iavor, please speak up if you find this is too much and would rather have this assigned to someone else. Iavor, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Please Review: Allow ScopedTypeVariables to refer to types (#128), Shepherd: Iavor
by Joachim Breitner 15 Jul '18

15 Jul '18

Dear Committee, this is your secretary speaking: Allow ScopedTypeVariables to refer to types, by myself https://github.com/ghc-proposals/ghc-proposals/pull/128 I propose Iavor as the shepherd. He is just too efficient an shepherd, and the only non-chair-member without an open proposal on his plate right now. Iavor, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0