October 2020 - ghc-steering-committee

Re: [ghc-steering-committee] Please review #281: Visible 'forall' in types of terms
by Spiwack, Arnaud 15 Oct '20

15 Oct '20

There has been conversation to this effect on the Github PR, for a day or so, starting at https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-707033… . But I wanted to point out that there are really two, interlocked, yet distinct, parts in this proposal. 1. Having a `forall a ->` construct for types of terms 2. How is `f blah` parsed if `f` has type `forall a -> …`? I am definitely sympathetic to (1). As much as I like my `f @…`s I am bound to admit that it produces error messages from the 7th Circle of Hell. And, since it's a very useful pattern, making it "official" is rather neat a plan on paper. But (2) is very very difficult, because we have really two grammars at play here: the grammar for term, and the grammar for types (I'll conflate grammar and name resolution in the following). In the `f @…` style, we switch to the type grammar to parse whatever's in the `@`. But if we want to to write type applications in the `forall a->` case as `f a`, then we sort of have to parse `a` as a term (though there is some leeway in name resolution). And that introduces all sorts of potentially weird behaviour (see the link above for a good documentation of what). Part of the difficulty, I should stress, is that, in types the apostrophe `'` means: I'm speaking of a data constructor, not a type constructor. Whereas in terms, it means: I'm opening a Template Haskell slice. Part of the impetus for the proposal actually going in the direction of parsing the type argument as a term, is the desire to eventually merge the terms and types grammars. I don't know how widespread this desire actually is (maybe this is something we should speak about). In my personal opinion, it's not a very plausibly achievable goal, nor is it particularly necessary for dependent types. (It does, of course, have a number of advantages, which is why Coq, Agda, and Idris do have a single grammar indeed). I think that I'd be happier if we had a sigil to switch between the type grammar and the term grammar. But, here, the issue is that nice sigils are harder and harder to come by. My point, though, is that while this proposal may look like it has a small scope, it actually is a fairly large and intricate proposal, and requires quite a bit of attention. /Arnaud On Mon, Oct 5, 2020 at 7:25 PM Iavor Diatchki <iavor.diatchki(a)gmail.com> wrote: > I've been following the discussion and I think we should keep it in the > "committee review" phase because > 1. The discussion is due to questions from the committee members, and > 2. Even though it seems like a lot, mostly it's been along the lines of > clarification and better phrasing of things, rather than big changes to the > proposal > > I don't feel strongly about it, so if others also think we should move it > to the discussion phase, I'd be happy to do so, I just don't want to loose > the steam we seem to have gathered :) > > Let me know, > -Iavor > > > On Mon, Oct 5, 2020 at 2:38 AM Simon Marlow <marlowsd(a)gmail.com> wrote: > >> There seems to have been a lot of ensuing discussion on this one, should >> it go back into the discussion phase? >> >> On Fri, 2 Oct 2020 at 20:06, Richard Eisenberg <rae(a)richarde.dev> wrote: >> >>> I'm in support of this proposal, but I've pushed back on a few softer >>> points. I've commented on GitHub. >>> >>> Richard >>> >>> On Oct 1, 2020, at 1:07 PM, Iavor Diatchki <iavor.diatchki(a)gmail.com> >>> wrote: >>> >>> Hello, >>> >>> Proposal #281 is ready for review by the committee. My recommendation >>> is to accept it, I've >>> written a summary of my understanding to the proposal and my >>> recommendation on the GitHub >>> thread, accessible through these links: >>> >>> https://github.com/ghc-proposals/ghc-proposals/pull/281 >>> >>> https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00… >>> >>> Let the discussion begin! >>> >>> -Iavor >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee(a)haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee(a)haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee(a)haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >

3 2

Please review #364: Unify Nat and Natural, Shepherd: Alejandro
by Joachim Breitner 12 Oct '20

12 Oct '20

Dear Committee, this is your secretary speaking: Unify Nat and Natural has been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/364 https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-uni… I’ll propose Alejandro as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 9

List archive failure
by David Feuer 09 Oct '20

09 Oct '20

There was a serious problem on haskell.org leading to a failure to archive several days of mailing list messages. As I am not subscribed to this list, I would appreciate if someone could let me know what, if any, messages have been sent about proposal #367 since the initial request.

2 1

GHC 2020
by Iavor Diatchki 04 Oct '20

04 Oct '20

Hello, I just had some fun and went through the list of GHC extensions in the manual, thinking of which ones might make a reasonable subset for a potential GHC2020. Below is the list I came up with. My reasoning was, roughy: * I wouldn't mind if these were on all the time * It is unlikely that turning on the extension will break something dramatically * It is unlikely that using the extension might lead to errors * The extensions are somewhat coherent * I explicitly included extensions that I personally don't use much, but I've heard that others like I wonder what others think of this list? What would you add/remove? -Iavor BlockArguments EmptyCase EmptyDatadecls ExplicitNamespaces ImportQualifiedPost LambdaCase MultiWayIf StandaloneDeriving BinaryLiterals HexFloatLiterals NumericUnderscores NamedFieldPuns RecordWildCards TupleSections ApplicativeDo RecursiveDo ParallelListComp BangPatterns PatternSynonyms ViewPatterns PatternGuards ForeignFunctionInterface CApiFFI RankNTypes ExistentialQuantification ScopedTypeVariables TypeSynonymInstances ConstraintKinds StandaloneKindSignatures KindSignatures TypeOperators

8 39

Please review #281: Visible 'forall' in types of terms
by Iavor Diatchki 02 Oct '20

02 Oct '20

Hello, Proposal #281 is ready for review by the committee. My recommendation is to accept it, I've written a summary of my understanding to the proposal and my recommendation on the GitHub thread, accessible through these links: https://github.com/ghc-proposals/ghc-proposals/pull/281 https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00… Let the discussion begin! -Iavor

2 1

Please review #283: Local modules, Shepherd: Arnaud
by Joachim Breitner 01 Oct '20

01 Oct '20

Dear Committee, this is your secretary speaking: Local Modules has been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/283 https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/00… I’ll propose Arnaud as the shepherd. Please note that Richard writes > The main alternative to this proposal is #295. It is probably worth > it for at least the committee shepherd to read #295 in concert with > this current proposal, to see which approach they like more. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1