September 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 #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

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

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 01 Oct '18

01 Oct '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 01 Oct '18

01 Oct '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

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

01 Oct '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 01 Oct '18

01 Oct '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 01 Oct '18

01 Oct '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 25 Sep '18

25 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