January 2018 - ghc-steering-committee

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

Proposal: Or patterns (#43)
by Manuel M T Chakravarty 19 Jun '18

19 Jun '18

Folks, I am sorry for taking a long time to get us going on this proposal. The ”Or pattern” proposal is about an extension to pattern matching: (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-pa… (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 Its basic idea is simple: allow multiple alternative patterns for each alternative during pattern matching. Unfortunately, the interaction with guards and some other languages features makes it significantly less straight forward than one might initially think. I propose to accept this proposal provided we can agree to use the ”first semantics” (aka single-match semantics) — see https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-pa… My reason for insisting on the first semantics is that it is a simple extension of the existing pattern semantics in the Report, whereas the second semantics requires a more profound, non-local change. This, in particular, also makes it easier to understand the implications of the first semantics. (Also, OCaml has made that same choice.) However, even with the first semantics, I still have one concern about this proposal. The story about the interaction with existential types is currently only partial and there is no discussion of the interaction with GADTs. It might be reasonable to ask for a complete specification of the interaction with these features before making a final determination on this proposal. Nevertheless, this proposal is quite elaborate and quite some work has gone into it. Hence, I think, we owe it the authors of the proposal to at least make a preliminary determination at this point. (In particular, if it is not going to fly regardless of how GADTs are handled, we should say so now.) Cheers, Manuel PS: It is worth noting that Swift solved the problem of deciding between the first and second semantics by choosing a syntax that avoids the ambiguity: <https://developer.apple.com/library/content/documentation/Swift/Conceptual/…>. It is difficult to adapt this syntax to Haskell. If it where possible, I think, this would be the best solution.

6 14

Please review: Mutable constructor fields, Shepherd: Ryan Newton
by Joachim Breitner 08 May '18

08 May '18

Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/8 was brought before the committee, by our own Simon Marlow. I propose Ryan Newton as the Shepherd, because he asked for it :-) Ryan, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

7 18

Committee Discussion : Lazy unboxed tuples
by Ryan Newton 06 May '18

06 May '18

Dear Committee, The public discussion <https://github.com/ghc-proposals/ghc-proposals/pull/35> for this one <https://github.com/goldfirere/ghc-proposals/blob/unbanged-strict-patterns/p…> has happened, now for 4 weeks of committee discussion and final accept/reject. In that public discussion, you can see on Jan 11 options broken down as (1),(2),(3), with this proposal being (1). This seems to have stopped in a weird place where there was some substantial argument for (2) and (3) in the latter half of the comments, but the proposal is for (1). Richard, one bit that threw me off was this: *"we should require the bang even on bare variables, but that would break a lot of code I think."* Because that makes it seem like in spite of this cleaning-up proposal, GHC still has a basically inconsistent position on how to interpret variable-bindings of unlifted kind in patterns. Discuss? -Ryan On Tue, Jul 11, 2017 at 11:08 AM, Joachim Breitner <mail(a)joachim-breitner.de > wrote: > Hi, > > it is by Richard, I just got the URL wrong. The right pull request is > https://github.com/ghc-proposals/ghc-proposals/pull/35 > sorry for that. > > Using this thread is fine. > > Joachim > > Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton: > > Just to clarify, this is proposed by a user "winterland". I.e. not > > Richard, right? In the process document it is the author that "brings > > it before the committee" correct? > > > > I checked and it looks like our process document does not specify the > > means of our committee discussion. I propose we discuss this one > > right here on this thread, which we've already got sitting in our > > inboxes. > > > > Best, > > -Ryan > > > > > > On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner <mail@joachim-breit > > ner.de> wrote: > > > Dear Committee, > > > > > > this is your secretary speaking: > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/45 > > > was brought before the committee, by our own Richard. > > > > > > I propose Ryan Newton as the Shepherd, just to rotate this role > > > properly. > > > > > > Ryan, please reach consensus as described in > > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > > > I suggest you make a recommendation about the decision, maybe point > > > out > > > debatable points, and assume that anyone who stays quiet agrees > > > with > > > you. > > > > > > > > > Greetings, > > > Joachim > > > > > > > > > -- > > > Joachim Breitner > > > mail(a)joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > > > > > -- > Joachim “nomeata” Breitner > mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata(a)debian.org > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee(a)haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > >

5 6

Proposal: Embrace Type in Type
by Iavor Diatchki 25 Apr '18

25 Apr '18

Hello, I am the shepherd for pull request #83 "Embrace Type in Type" ( https://github.com/ghc-proposals/ghc-proposals/pull/83) and so I'd like to hear your thoughts about the proposal. In short, the proposal has two parts: 1. Deprecate the use of `*` for the kind of inhabited Haskell types, and replace it with `Type`. 2. Deprecate extension `TypeInType`, and move its functionality to extension `PolyKinds`. At first I was quite skeptical about both of these, but after some thought I've realized that most of my concerns are not so much about Type in Type, but rather about the data promotion mechanism, and so I won't discuss them in this e-mail. As such, I think I would be OK with part 2. In particular, I like that when using TypeInType, one is explicit about kind parameters, as the implicit parameters of `PolyKinds` can be quite confusing. Technically, being explicit about kind parameters is an orthogonal issue to mixing up types and kinds, but this is where we are at the moment, and I think `PolyKinds` is probably more useful with `TypeInType`. Part 1 of the proposal is obviously just a syntactic thing, but I am a bit concerned about it. In part because I actually tried for a while to use `Type` instead of `*`, and I found that the resulting kind signatures looked much more complicated. Quite possibly this is because I am very used to using `*` and eventually I would adjust, but things just ended up being much longer. It also seems unfortunate that this would break quite a lot of code, and obsolete a bunch of documentation and tutorials online. So while I understand the reason for the proposal (the confusion between `*` the type function, and `*` the kind), I am not very keen on making this change. The proposal also suggests another extension, `StarIsType`, and when enabled `*` will always refer to the kind, and never to the type function. I am even less keen about this option, as I think it is better to pick a single notation and stick with it. I'd love to hear what others think! -Iavor

7 36

Please review: embrace Type::Type, Shepherd: Iavor
by Joachim Breitner 11 Feb '18

11 Feb '18

Dear Committee, this is your secretary speaking: Richards proposes to merge -XTypeInType into -XPolyKinds and -XDataKinds https://github.com/ghc-proposals/ghc-proposals/pull/83 I propose Yavor Diatchki as the Shepherd. Yavor, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation 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: accept "add incomplete-uni-patterns and incomplete-record-updates to -Wall"
by Simon Marlow 08 Feb '18

08 Feb '18

I propose that we accept the proposal add incomplete-uni-patterns and incomplete-record-updates to -Wall https://github.com/ghc-proposals/ghc-proposals/pull/71 <https://github.com/ghc-proposals/ghc-proposals/pull/71> Both warnings are avoidable and considered bad style, which makes them appropriate to include in -Wall. The reason that -Wincomplete-uni-patterns wasn't originally made part of -Wall was due to worries about noisiness ( https://ghc.haskell.org/trac/ghc/ticket/4905) but that's not a valid concern. -Wall is intentionally a moving target, if you want to stay Wall-clean you accept that new compiler releases may entail some work. Basically I think this is a no-brainer. Cheers Simon

5 4

Deadlines for Shepherds?
by Joachim Breitner 08 Jan '18

08 Jan '18

Hi, you know that I like slim smooth processes with not too many rules, and our current process worked pretty nicely for the first few proposals. But now it seems that we lost some steam, and a fair number of proposals are stuck waiting for their Shepherd to make progress. Does this mean that people simply need deadlines for work to be done? Do you want deadlines? Also, I am happy to re-assign some stalled proposals to new shepherds. Does anyone want to volunteer recommending a decision for one or more of these proposals: Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Deprecate STM invariant mechanism https://github.com/ghc-proposals/ghc-proposals/pull/77 -Wall to include incomplete-uni-patterns and incomplete-record-updates https://github.com/ghc-proposals/ghc-proposals/pull/71 Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 3

Status
by Joachim Breitner 06 Jan '18

06 Jan '18

Dear Committee, welcome to the new year 2018. Since the last status update, we * were asked to review these proposals: - merge -XTypeInType * accepted the following proposals: - /none/ * sent the following proposals back for further refinement - /none/ * rejected the following proposals: - /none/ On our table at the moment are: Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Or Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Chakravarty Status: Committee deliberation ongoing, likely expecting changes. Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Roman suggested changes, a slow discussion is happening. Deprecate STM invariant mechanism https://github.com/ghc-proposals/ghc-proposals/pull/77 Shepherd: Manuel Chakravarty Status: Waiting for Manuel to make a recommendation -Wall to include incomplete-uni-patterns and incomplete-record-updates https://github.com/ghc-proposals/ghc-proposals/pull/71 Shepherd: Simon Marlow Status: Waiting for Simon to make a recommendation Embrace (Type :: Type) https://github.com/ghc-proposals/ghc-proposals/pull/83 Shepherd: Iavor Diatchki Status: Waiting for Iavor to make a recommendation Besides these, there are some proposals actively under discussion. You can always check them out at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no… Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0