December 2017 - 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

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

18 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 05 May '18

05 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

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

Status
by Joachim Breitner 06 Dec '17

06 Dec '17

Dear Commmittteee, Since the last status update, we * were asked to review these proposals: - visible dependent quantification - Deprecate STM invariant mechanism - add incomplete-uni-patterns and incomplete-record-updates to -Wall - Block arguments * accepted the following proposals: - underscores in literals - Block arguments * sent the following proposals back for further refinement - /none/ * rejected the following proposals: - /none/ * Had a discussion how to scale the committee process to “big” proposals like linear types. 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: Manuel suggests acceptance, committee deliberation ongoing Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Waiting for Roman to make a recommendation 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 Dear shepherds, there is work waiting for you! 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

Underscores in literals
by Iavor Diatchki 06 Dec '17

06 Dec '17

Hello, This e-mail is about pull request #76, to allow underscores in numeric literals: https://github.com/takenobu-hs/ghc-proposals/blob/numeric-underscores/propo… In short, this is a very simply feature, which modifies the notation for numeric literals to allow writing underscores (_) in the middle of literals. The underscores are only to increase readability, and have no effect on the meaning of the program. So, for example, I could write things like: 10_000_072 or 0xFFFF_FA10. Many other languages have a similar feature (especially hardware specification languages) and I see no downsides to it, so I think we should accept it. Please respond to this e-mail if you have objections. Cheers, -Iavor

5 6

Proposal: BlockArguments (Shepherd: Joachim)
by Joachim Breitner 06 Dec '17

06 Dec '17

Dear committee, the BlockArguments (former ArgumentDo) proposal was brought before us: https://github.com/ghc-proposals/ghc-proposals/pull/90 I’ll shepherd this myself. The idea is to not require parenthesis around block syntax elements such as lambda expressions, let bindings, if-then-else, case-of and (in particular) do expressions. The change to the grammar to enable that is actually a simplificiation (it removes one non-terminal, lexp). Variants proposed are: * do this only for `do` in argument position, or * do it for all blocks, but only in function argument positions. I am fond of this proposal, because it allows code with less parenthesis to be written. If Haskell was written from ground up, I believe there would be little opposition to this setup, and maybe we would not have had to hack higher-rank support into ($), as the idiom `runST $ do …` would just be `runST do …`. Another argument in favor of it is the mentioned simplificiation of the grammar rules. I am aware that reading the parenthesis-free code feels strange to many, but I not overly worried about that: Every change feels strange, and in this case, only code that is otherwise illegal is affected. Akio has indicated that he is willing to work on the implementation. Therefore, I suggest that we accept this proposal. Please discuss (or voice you silent agreement). Regards, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 5