- ghc-steering-committee

Please review #343: BangPatterns by default, Shepherd: Simon PJ
by Joachim Breitner 22 Jul '20

22 Jul '20

Dear Committee, this is your secretary speaking: BangPatterns by default has been proposed by AndreasPK https://github.com/ghc-proposals/ghc-proposals/pull/343 https://github.com/AndreasPK/ghc-proposals/blob/bang_by_default/proposals/0… I propose Simon PJ as the shepherd, as this affects a relatively fundamental principle of our work so far (all changes are guarded by language extensions), and accepting/rejecting this proposal likely has precedence character. 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 2

Haddock
by Richard Eisenberg 14 Jul '20

14 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 16 Jun '20

16 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 06 Jun '20

06 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

#195
by Simon Peyton Jones 27 May '20

27 May '20

Iavor Matthew says > Please can we move on from this proposal! You are the shepherd. Iavor. Bringing the discussion to a conclusion is your role. I'm not arguing against acceptance. I have reservations about our overall TH story, but we should not let the best be the enemy of the good. Let's keep moving. Simon

3 2

Please review again: Make Q (TExp a) into a newtype #195
by Iavor Diatchki 22 May '20

22 May '20

Hello, I am the shepherd for #195, about a small change to TH, to wrap `Q (TExp a)` into a newtype. This would be quite handy for a variety of reasons described in the proposal and the comments on the proposal thread: https://github.com/ghc-proposals/ghc-proposals/pull/195 During the last discussion we requested the proposal to be modified to clarify some points. Matt has done that, so it is time for another review. The previous discussion thread is here: https://mail.haskell.org/pipermail/ghc-steering-committee/2019-November/001… I still think this is a good idea, and recommend acceptance. Since we've already discussed this once, I'll assume acceptance in about a week, if I don't hear from anyone, although I'll wait until at least Simon PJ and Richard confirm that the issues they raised last time have been addressed. -Iavor

2 2

#216: Qualified Do again, recommendation: accept the alternative
by Joachim Breitner 22 May '20

22 May '20

Dear Committe, Proposal: https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-d… Discussion (long, sorry): https://github.com/ghc-proposals/ghc-proposals/pull/216 Summary: Over a year ago (on my birthday then) Arnaud created a “local do” proposal that would be a more targetted variant of RebindableSyntax, just for “do”. In June, we sent it back because a simple syntactic desugaring to records didn’t quite seem right (bad type inference). In March, the authors can back with an alternative, which was using a Module name instead of a value of record type to indicate that monadic operations to use. This nicely solved the type system issues and meant that the translation can happen (in principle) in the parser or renamer stage. But some of us noticed that a builder record is nicer after all, and we can fix the type system issues, mostly by introducing a new concept of “fully settled type”; with analogies to TH stage restrictions. The authors updated the proposal accordingly, but also list the alternatives in the documents. Based on the GitHub thread we have varying opinions among the committee. Nevertheless, I think the authors have done a great and patient job so far, so we owe them a hopefully conclusive discussion. The main question we have to decide is: record-based or module based Record based: ➕ A single entity one can import, reexport, even rebind ➕ A single entity that can carry the documentation ➕ One module can export multiple builders ➕ Looking forward, the builder could be dynamically constructed (i.e. a local value) ➕ Concept of fully settled may be useful elsewhere in the future and can be expanded ➖ Needs a new concept of “fully settled” that we don’t have elsewhere ➖ Initially, “fully settled” introduces staging restrictions; builder values may not be usable everywhere where they are in scope. ➖ Lots of fluff on the defining side (define a likely one-off record + a value) ➖ May require extensions (e.g. RankNTypes, ImpredicativeTypes) on the defining side, even for a builder for the “normal” Monad (see https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-600746… for an example for the previous two points) ➕ Some compositionality (functions modifying builders), but ➖ not as universal as one would hope, as there is not a single builder type (different qualified monads likely use different record type) ➕ Can support “passing arguments to do” via `(monadBuilder @Maybe).do` or `(b cfg).do` (once the notion of “fully settled” is powerful enough) Module based: ➕ Simpler to specify and understand: Only affects parsing, possibly renaming. No interactions with the type system. ➕ Works out of the box with, say, `Prelude.` as the qualifier ➕ Benefits from future improvements to the module system ➖ Would need separate syntax for “passing arguments to do”, should we want that ➕ But if we had that, it can implement the record-based approach, by passing a recoord to a suitable qualified do monad, as Iavor observes: https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-598859… The module-based approach would additionally raises the question whether * the desugaring to M.(>>) means (>>) as provided by (some) M”, akin to how plain do notation works. * the desugaring to M.(>>) means just that (and requires (>>) to be imported as well), akin to how RebindableSyntax works There was also a brief discussion of whether this should extend the set of operations involved to a `last` function that is used in the translation rule for a single-statement do notation, but it did not catch on. Recommendation: While both approaches are reasonable and have their merits, I recommend to accept the Module based approach. It supports most use-cases presented so far, in particular the Linear.do as envisioned by the authors, so it seems good enough™. Furthermore, it certainly is significantly simpler, given that it can be specified purely in terms of naming things, so we have a higher chance that this will work well with other existing and future language features. Should the committee follow that decision, I recommend to pick the variant where the value does not need to be in scope, so that its mechanism is close to the normal do notation, and that you can write import Linear (runLinear, other, stuff) … Linear.do { … } without mucking with qualified imports or shadowing (>>). It seems odd to require the user to add ((>>), (>>=), fail) to an import list when you don’t actually mention that name anywhere. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

11 59