- ghc-steering-committee

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

Please Review #170: Uppercase OverloadedLabels, Shepherd: Vitaly Bragilevsky
by Joachim Breitner 30 Sep '18

30 Sep '18

Dear Committee, this is your secretary speaking: Uppercase OverloadedLabels, by howtonotwin Maguirer, was proposed https://github.com/ghc-proposals/ghc-proposals/pull/170 I propose Vitaly Bragilevsky as the shepherd. 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

StableName guarantee (#163), recommendation: accept
by Simon Marlow 30 Sep '18

30 Sep '18

The proposer wants to change the implementation of StableNames, and noticed that the existing implementation has the property that, for two StableNames s1 and s2 that are currently live, hashStableName s1 == hashStableName s2 ==> s1 == s2 this property is not documented. As far as we know, there isn't any code in the wild that relies on it. In fact, relying on it would be tricky due to the requirement that s1 and s2 have to be live - as soon as a StableName becomes unreachable from the GC's point of view, the index into the table that is used to provide the result of hashStableName is reused. The proposal is to remove this property. Well, a future refactoring of the StableName implemnetation would actually remove the property, the proposer wants the committee to consider whether the property in question is worth keeping (and therefore documenting). I think it's pretty clear that we don't want to document this property, because in order to do so we would have to give a precise definition of what "live" means, which is not possible. Furthermore, we don't know of any use cases in the wild. So, let's accept the proposal. Cheers Simon

2 2

GHC steering committee lunch at ICFP?
by Richard Eisenberg 24 Sep '18

24 Sep '18

Hi all, I imagine many of us are currently en route to St. Louis for this year's week of λ. I thought it might be nice for us steering committee members to gather, perhaps over lunch. My goal in organizing this is twofold: - Simply to gather. I enjoy working with you all and it's great to continue building social connections. - To figure out some concrete direction about the Linear Types proposal. As its shepherd, I feel responsible for moving it along and -- while there remains a slow drip of questions/answers/opinions on the ticket -- I don't sense that we're getting toward any concrete action that we can share with the authors of the proposal. I recognize that not all members of the committee will be at ICFP. Accordingly, I hope we can find a volunteer to take minutes to share with those not present. No concrete action will be committed to without posting here for discussion first. In addition, I'm sure we can find a way for folks to join the meeting remotely, if the timing works. I arbitrarily propose Monday lunch for this meeting. Feel free to counterpropose. See you soon, Richard

8 14

Proposal: Lazy unboxed tuples / warn on unbanged strict patterns (#35); Recommendation, attempt 2: Accept
by Vitaly Bragilevsky 12 Sep '18

12 Sep '18

Hi, This is my revised recommendation for the lazy unboxed tuples proposal ( https://github.com/ghc-proposals/ghc-proposals/pull/35) It is already implemented, and I don't see strong opposition to it, so my recommendation is ACCEPT. Silence is understood as agreement. Regards, Vitaly

2 2

Proposal: Define Kinds Without Promotion (#106)
by Eric Seidel 12 Sep '18

12 Sep '18

Hi everyone! This proposal would allow the declaration of new kinds and type constructors, without the associated data constructors that would have been generated by -XDataKinds. https://github.com/yav/ghc-proposals/blob/data-kind-only/proposals/0000-typ… It introduces a new language extension, -XTypeData, which allows declarations like the following: type data Universe = Character | Number | Boolean This introduces a new kind, Universe, with three associated type constructors Character :: Universe Number :: Universe Boolean :: Universe Notably, no data constructors are introduced. The proposal aims to solve several usability issues with -XDataKinds: 1. We often don't want the data constructors, which simply pollute the value namespace. 2. We cannot easily control the export behavior of promoted types (instead we resort to tricks like the alias `type Character = 'Character`). 3. The name resolution rules involving promoted types can be confusing. I find these issues (particularly #2) compelling, and the community response seems to be mostly positive, so I recommend accepting the proposal. I'm not particularly fond of the proposed syntax (`type data` makes it sound like we're doing something with data constructors, which is precisely what we're NOT doing), but the proposal has already had a good bit of bikeshedding, and people seem mostly happy with the current syntax, so I think we should probably stick with `type data`. Eric

6 24

Please Review: StableName guarantee (#163), Shepherd: Simon Marlow
by Joachim Breitner 30 Aug '18

30 Aug '18

Dear Committee, this is your secretary speaking: Remove an undocumented StableName guarantee, by David Feuer, was proposed https://github.com/ghc-proposals/ghc-proposals/pull/163 I propose Simon Marlow as the shepherd. 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

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

Proposal: Lazy unboxed tuples / warn on unbanged strict patterns (#35); Recommendation: Reject
by Vitaly Bragilevsky 20 Aug '18

20 Aug '18

Hi, the lazy unboxed tuples proposal ( https://github.com/ghc-proposals/ghc-proposals/pull/35) was under discussion for a long period of time (more than a year and a half since submission). As a shepherd to this proposal I recommend rejection based on the following: * there is no clearly articulated motivation in favor of this proposal despite complying with the Manual; * implementing this would lead to hard-to-trace performance issues in the users code (due to move from strictness in current GHC behaviour to laziness); * it looks like the change (B) of the proposal (warn an unbanged strict patterns) meets no complains, so it is better to be resubmitted as a separate proposal; * if resubmitted separately the change (A) should elaborate on desugaring to make potential performance drawbacks clear; * it seems (maybe mistakenly) that the author has lost his interest in this proposal. Although silence is undestood as agreement, I'd be glad to receive a feedback on this recommendation. Regards, Vitaly

5 7