June 2020 - ghc-steering-committee

Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel
by Joachim Breitner 08 Jan '22

08 Jan '22

Dear Committee, this is your secretary speaking: NoFallibleDo proposal has been proposed by Cale https://github.com/ghc-proposals/ghc-proposals/pull/319 https://github.com/obsidiansystems/ghc-proposals/blob/no-fallible-do/propos… I propose Eric Seidel 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 18

Haddock
by Richard Eisenberg 13 Jul '20

13 Jul '20

Hi committee, With a steady level of activity adding new features to GHC, I fear we may be forgetting one important downstream client: Haddock. For a nice example of how our decisions can cause trouble, see https://github.com/goldfirere/singletons/issues/466#issuecomment-646117067. Despite appearing on the singletons bug tracker, that comment is all about Haddock support for https://github.com/ghc-proposals/ghc-proposals/blob/3dfec03b11e8829d7febbb7…, the -XStandaloneKindSignatures extension. This makes me wonder: should we invite a maintainer of Haddock to be an ex-officio (and voting) member of the committee? This would have two salutary effects: - It would force us to consider an important aspect of the user experience -- reading documentation -- of newly proposed features. - It would force us to give Haddock a heads-up about new features they may want to incorporate. If we don't think we need an ex-officio committee member, then perhaps we should instead require future proposals to describe a plausible impact on Haddock. I say "plausible impact" to suggest that the proposal text would not be binding on Haddock (which would be awfully dictatorial of us), but that it gives Haddock a starting place to consider their own design, while forcing proposers to think about this important-but-easily-neglected aspect of language evolution. What do we think? Richard

8 15

Please review #292: ByteArray Literals, Shepherd: Vitaly
by Joachim Breitner 24 Jun '20

24 Jun '20

Dear Committee, this is your secretary speaking: ByteArray Literals has been proposed by Andrew Martin (based on a proposal by Oleg Grenus) https://github.com/ghc-proposals/ghc-proposals/pull/292 https://github.com/andrewthad/ghc-proposals/blob/bytearray-literals/proposa… I propose Vitaly 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/

3 3

Please review #333: Defer parse errors, Shepherd: Tom Harding
by Joachim Breitner 15 Jun '20

15 Jun '20

Dear Committee, this is your secretary speaking: Defer parse errors has been proposed by our own Alejandro Serrano Mena https://github.com/ghc-proposals/ghc-proposals/pull/333 https://github.com/serras/ghc-proposals/blob/allow-unfinished-do/proposals/… I propose Tom 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/

1 0

Proposal #274: Quicklook impredicativity, recommendation: accept
by Spiwack, Arnaud 15 Jun '20

15 Jun '20

Dear all, Last time around that we had a discussion about this proposal, the authors asked to have some more time to revise a few things. Since then, the proposal has been simplified, and the paper accepted (congratulations!). Last time around, those of us who opined were mostly in agreement with accepting the proposal, though there were some distracting complications. Which have since been forked (and accepted) as proposal #287 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-s…>. I do believe that this iteration of the proposal is a no-brainer. It simply gives a clear semantics to the unspecified -XImpredicativeTypes. It’s useful, and an implementation already exists (!3220 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3220>). The summary of the proposed specification is: to instantiate a type variable to something of the form forall a. …, go through arguments and look for an absolutely necessary such instantiation (which will happen when there is a data constructor: [a] ~ [forall b.t] iif a = forall b.t). The only point which we may want to discuss is ($), which currently has an ad hoc typing rule baked in the type checker. The proposal suggests removing this baked in rule, and replacing it with making ($) always use the -XImpredicativeTypes typing rule. An alternative, of course, is to simply not treat ($) any specially, and require -XImpredicativeTypes to be explicitly turned on when one wants runST $ do …. But, as the proposal points out, this would break a lot of existing programs. So I agree with the proposal’s choice. In summary, I recommend accepting this proposal in its current state.

4 7

Please review #303: Constraint based arrow notation, Shepherd: Chis Done
by Joachim Breitner 05 Jun '20

05 Jun '20

Dear Committee, this is your secretary speaking: Constraint based arrow notation has been proposed by Aleix King https://github.com/ghc-proposals/ghc-proposals/pull/303 https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-no… I propose Chris Done as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

5 14

Please review #270: Extend Term-Level Lookup rules
by Iavor Diatchki 02 Jun '20

02 Jun '20

Hello, I am the shepherd for proposal #270, and it is time for the committee to review the proposal. The discussion and the proposal are available here: https://github.com/ghc-proposals/ghc-proposals/pull/270 Here is my summary of the proposal: The proposal aims to solve the "namespace problem" which appears to largely be related to fact that Haskell has two namespaces, and so types and values may have the same name. Proposed changes: 1. Change the scoping rules for the language so that type names are in scope at the value level, but values always shadow types. 2. Add a new form of import, which can import only the names from a particular names space 3. Change the way built-in syntax for tuples and lists works and deprecated ' and '' from DataKinds and TH respectively. This is a bit elaborate, have a look in the proposal for details 4. Add a bunch of warnings that would trigger if you wrote code that made use of Haskell's different name spaces My recommendation is that the proposal is rejected, as I don't think that these changes would help Haskell programmers, at least based on the way I use Haskell. In particular, here are my thoughts on each of the above bullets: 1. This is mostly about passing type arguments to functions---I would prefer a notation that is more explicit about the fact that we are passing in a type, and not just a normal argument. 2. When I group things into modules, it is usually because they are intended to be used together. I think I would rarely want to import only the types or only the values in a module, so I imagine it would be much more common to have to write two imports. 3. This is quite an intrusive change, that is likely to break code. I am also not keen to have to use type families, every time I want to use a tuple. 4. Using the same name for a data constructor and a type is very common in Haskell. I find it particularly useful when defining records. I don't need warnings to let me know that I've done it, as it is highly unlikely that I did it on accident. -Iavor

5 6