- ghc-steering-committee

Proposal #173: The dot type operator, rec: accept
by Eric Seidel 05 Nov '18

05 Nov '18

Hello, This proposal would extend the parser to allow the '.' character to appear in type operators, allowing one to write code like the following: ``` type (f . g) x = f (g x) foo :: (Maybe . Either Int) Bool foo = Just (Right True) ``` I recommend we accept the proposal, as it would resolve an odd inconsistency between the term and type languages. The main downside seems to be that combining a type-level '.' with a 'forall' is a bit hard to read, but I think the benefits of a more consistent syntax outweigh this concern. Eric

5 4

Proposal #168: fail with OverloadedStrings, rec: accept
by Joachim Breitner 21 Oct '18

21 Oct '18

Dear committee, welcome back from ICFP! Those who missed it: it was great, watch the videos, come to Berlin next year. Shayne Fletcher proposed that in the presence of both RebindableSyntax and OverloadedStrings, the implicit calls to fail produces by the compiler should wrap the arguments in `fromString`: https://github.com/shayne-fletcher-da/ghc-proposals/blob/fail-rebindable-wi… I’ll shepherd that myself. I agree with Neil Mitchell in the assessment that this feels more like a bug fix than a proposal, and support acceptance. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Proposal #174: Lower precedence for {-# UNPACK #-}, rec: accept
by Joachim Breitner 20 Oct '18

20 Oct '18

Dear committee, Vladislav proposed that we lower precedence for {-# UNPACK #-}: https://github.com/int-index/ghc-proposals/blob/unpack-pragma-precedence/pr… I’ll shepherd that myself. Simon already nodded, it’s half implemented and a clear win. Happy to recommend acceptance. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Linear types (#111): conditional acceptance
by Richard Eisenberg 19 Oct '18

19 Oct '18

Hi all, Several members of the steering committee met at ICFP to discuss the Linear Types proposal, #111. While some concerns were raised about the utility of the proposed approach (as also explained on the GitHub trail), the committee agreed that the best way forward would be to accept the proposal. I thus propose *conditional acceptance*, subject to these conditions, which were discussed at ICFP: 1. Error messages must remain free of mention of linear types, unless -XLinearTypes is in effect (or some flag like -fprint-linear-types is on). The same must be true of using the `:type` facility in GHCi. 2. Type inference must remain backward-compatible. All programs accepted today must be accepted when -XLinearTypes is not in effect. Ideally, these programs would also be accepted when -XLinearTypes is in effect, but there can be some wiggle room here. 3. Compile times for programs without -XLinearTypes must not unduly increase. Anything approaching or over a 2% across-the-board increase in compile times would be a cause for concern. 4. There must be no degradation in runtime performance of GHC-compiled programs. Linear types in Core might, for example, make some optimizations harder to apply; however, we must find a way to get runtime performance on par with what we have today. 5. There must be a story for a migration of `base`. The committee is concerned that, once linear types hits, there will be a great demand to incorporate linear types into `base`. (Note that `fmap` may want a linear type, and due to Functor's status as a superclass of Monad, `fmap` is really baked in.) How will this work? In particular, how will Haddock render newly-linearized types? 6. The theory of the linear types must be sound. This seems to be the case today, but as things evolve, we want to state explicitly that this must remain true. In particular, we must be able to rely on the safety of using linear mutable arrays. 7. There must be a specification (in some typeset document) of the new core language, written out for public inspection. If the final version of this should violate these prescriptions, it does not immediately mean we are at an impasse -- it just means that we need to have more discussion. Before officially posting this on #111 on behalf of the committee, I'd like some feedback on this recommendation. As usual, I'll take silence for agreement. Discussion period: 1 week (shortened due to the fact that many have already participated in formulating this list) Thanks! Richard

3 4

Please Review: Show Types as Symbols (#164), Shepherd: Richard Eisenberg
by Joachim Breitner 17 Oct '18

17 Oct '18

Dear Committee, this is your secretary speaking: Provide a primitive to show types as Symbols, by Sandy Maguirer, was proposed https://github.com/ghc-proposals/ghc-proposals/pull/164 I propose Richard as the shepherd, he already showed interest in this proposal. 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/

3 2

Please review #166: List instances for a type in GHCi, Shepherd: Iavor
by Joachim Breitner 11 Oct '18

11 Oct '18

Dear Committee, this is your secretary speaking: List instances for a type in GHCi, by Xavier Denis, was proposed https://github.com/ghc-proposals/ghc-proposals/pull/166 I propose Iavor 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

Please review #173: The dot type operator, Shepherd: Eric Seidel
by Joachim Breitner 06 Oct '18

06 Oct '18

Dear Committee, this is your secretary speaking: The dot type operator, by Vladislav Zavialov, was proposed https://github.com/ghc-proposals/ghc-proposals/pull/173 I propose Eric Seidel 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 #170: Uppercase OverloadedLabels, rec: accept
by Vitaly Bragilevsky 01 Oct '18

01 Oct '18

Hi all, As a shepherd to the proposal #170, Uppercase OverloadedLabels ( https://github.com/ghc-proposals/ghc-proposals/pull/170) proposed by howtonotwin, I recommend acceptance. It is proposed to allow the string after # (with -XOverloadedLabels) to start uppercase thus looking like a constructor name in addition to a variable name as we have now. The proposal is clear, there are no known pitfalls. I suggest having two weeks for discussion. Silence is understood as an an agreement with this recommendation. Regards, Vitaly

3 2

Status
by Joachim Breitner 30 Sep '18

30 Sep '18

Hi committee, post ICFP status update. Since the last status update, we * were asked to review these proposals: #163 StableName guarantee (Shepherd: Simon M.) #164 Show Types as Symbols (Shepherd: Richard) #168 fail with OverloadedStrings (Shepherd: Joachim) #170 Uppercase OverloadedLabels (Shepherd: Vitaly) * got a recommendation from shepherds about: #81 Syntax for visible dependent quantification (rec: accept) #54 Top-level kind signatures (rec: accept) #106 Define Kinds Without Promotion (rec: accept) #35 Lazy unboxed tuples (rec: reject, I mean, accept) #163 StableName guarantee (rec: accept) #168: fail with OverloadedStrings (rec: accept) * decided about the following proposals #126 Type applications in patterns (accept) #35 Lazy unboxed tuples (accept) #106 Define Kinds Without Promotion (accept) #163 StableName guarantee (accept) #81 Syntax for visible dependent quantification (accept) #54 Top-level kind signatures (accept) With Roman’s proposals successfully concluded, I’d like to officially thank him for his contributions to the committee, and relieve him from his obligations as a committee member. We currently have to act on the following 9 proposals, which is 2 less than last round. Let’s make that a trend! Uppercase OverloadedLables https://github.com/ghc-proposals/ghc-proposals/pull/170 Shepherd: Vitaly Status: Waiting for recommendation. fail with OverloadedStrings https://github.com/ghc-proposals/ghc-proposals/pull/168 Shepherd: Joachim Status: Acceptance recommended Show Types as Symbols https://github.com/ghc-proposals/ghc-proposals/pull/164 Shepherd: Richard Status: Richard is discussing things with the authors Type annotated quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Shepherd: Manuel Status: Still waiting for recommendation. Manuel? Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Status: Still waiting for recommendation. This is pretty old! Linear types https://github.com/ghc-proposals/ghc-proposals/pull/111 Shepherd: Richard Status: acceptance-ish(?) … this is a hard one ExtraCommas https://github.com/ghc-proposals/ghc-proposals/pull/87 Shepherd: Chris Recommendation: accept Status: Met with some reservation. Chris, what is the status of discussion? Or-Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Recommendation: accept Status: Round 2 discussion ebbed down. Manuel? Bundling patterns with synonyms https://github.com/ghc-proposals/ghc-proposals/pull/28 Shepherd: Chris Recommendation: accept Status: Ongoing discussion, met with some resistance. Chris, what’s the status? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Proposal: Top-level kind signatures (#54)
by Roman Leshchinskiy 30 Sep '18

30 Sep '18

Hi everyone, The proposal is about adding stand-alone kind signatures for type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/54 The basic idea is to add support for kind signatures like this: type T :: Type -> Type -> Type data T a b = ... Signatures would be introduced by the keyword 'type' and could be provided for data types, type synonyms, type families and classes. The extension would be enable via -XTopLevelKinds. Additionally, complete user-supplied kind signatures (CUSKs, see https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext…) would be given a separate language extension, -XCUSKs which would be on by default for now but turned off in GHC 8.8 and then deprecated and removed. The proposal depends on #81. Feedback has been positive and this is rather cleaner than the current story so I'm in favour of accepting this. Like Richard, I'm not really happy with the name "TopLevelKinds", especially since signatures for associated types aren't even on the top level. Would something like StandAloneKinds or ExplicitKindSignatures be better? One minor point that isn't clear to me: the proposal says that "Associated types may be given kind signatures within their classes". Are type variables mentioned in the class head visible in the kind signature for the associated type? Thanks, Roman

4 3