April 2018 - ghc-steering-committee

Please Review: UnliftedArray# (#112), Shepherd: Simon Marlow
by Joachim Breitner 28 Apr '18

28 Apr '18

Dear Committee, this is your secretary speaking: UnliftedArray# has been proposed by Andrew Martin: https://github.com/ghc-proposals/ghc-proposals/pull/112 I propose Simon Marlow as the shepherd. Simon, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Status
by Joachim Breitner 25 Apr '18

25 Apr '18

Hi committee, the proposal process has become pretty popular, and it seems we are having trouble keeping up. There are a few proposals that needs shepherding … so please check if you are expected to make a recommendation or, if you have, if the discussion needs more guidance or can be closed. Since the last status update, we * were asked to review these proposals: - Provenance-Qualified Package Imports (Shepherd: Ben) - Quantified Constraints (Shepherd: Richard) - Kinds Without Promotion (Shepherd: Ryan) - DH quantifiers (Shepherd: me) - Top-level kind signatures (Shepherd: Roman) - Resurrect PatternSignatures (Shepherd: Chis) - forall {k} (Shepherd: Iavor) * got a recommendation from shepherds about: - :kind!! (accept) - Treat kind and type vars identically with `forall` (accept) - Binding existential type variables (reject) - Quantified Constraints (accept) * decided about the following proposals - :kind!! (needs revision) - Quantified Constraints (accept) - Source plugins (accept) - plugin recompilation avoidance (accepted, but proposal needs to be updated) - DH quantifiers (punted, now dormant) We currently have to act on the following 14 proposals, which is 2 more than a the time of the last the last status mail. Deriving Via https://github.com/ghc-proposals/ghc-proposals/pull/120 Shepherd: Joachim Status: Acceptance recommended Resurrect PatternSignatures https://github.com/ghc-proposals/ghc-proposals/pull/119 Shepherd: Chris Status: Waiting for recommendation. Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Status: Waiting for recommendation. Define Kinds Without Promotion https://github.com/ghc-proposals/ghc-proposals/pull/106 Shepherd: Ryan Status: Waiting for recommendation. kind and type vars https://github.com/ghc-proposals/ghc-proposals/pull/103 Shepherd: SPJ Status: Discussion ongoing forall {x}, https://github.com/ghc-proposals/ghc-proposals/pull/99 Shepherd: Iavor Status: Waiting for recommendation. Binding existential variables https://github.com/ghc-proposals/ghc-proposals/pull/96 Shepherd: Roman Status: Roman recommends to reject. Very active discussion going on, with an alternative proposal in #126. Embrace Type-In-Type https://github.com/ghc-proposals/ghc-proposals/pull/83 Shepherd: Iavor Status: We made progress. Iavor, Richard, do we have consensus now? Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: With #102 punted, discussion can and should start again. Top-level kinds signatures https://github.com/ghc-proposals/ghc-proposals/pull/54 Shepherd: Roman Leshchinskiy Status: Waiting for recommendation. Or-Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Status: Waiting for Manuel to make a recommendation Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Status: This is lingering since last July! Constraint vs. Type https://github.com/ghc-proposals/ghc-proposals/pull/32 Shepherd: Simon PJS (proposed acceptance) Status: Simon’s proposal was met with silence. Ergo accept? Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Inconclusive discussion that fell silent, but not the clear consensus that I’d like. Ryan, what is the status here? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 15

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

Constraint vs Type: I propose acceptance
by Simon Peyton Jones 24 Apr '18

24 Apr '18

Friends I propose that we support the GHC proposal "Declare Constraint is not apart from Type<https://github.com/ghc-proposals/ghc-proposals/blob/rae/constraint-vs-type/…>" Currently GHC operates an uneasy compromise: * Constraint and Type are treated as distinct in the type checker (e.g. do not unify) * But they are treated as the same in Core I have spent ages in discussion with Richard and others for how to fix this wart. Really, they should be either * completely different (like Int and Bool), or * completely the same (like [Char] and String). But both these stances have problems, and nothing satisfying has emerged. So this proposal simply fixes the worst aspect (unsoundness) of the current setup. So I regard it as a way to stay explicitly non-committal, leaving the main question open. There are a couple of clarifications I'd like which I've put on the discussion thread. Simon

3 4

Quantified Constraints (#109). Recommendation: accept
by Richard Eisenberg 23 Apr '18

23 Apr '18

The proposal for quantified constraints, #109, has been submitted for a decision. This proposal generalizes the syntax for constraints to include forall-quantification and premise constraints. For example: > data Rose f a = Branch a (f (Rose f a)) > > instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where > Branch x1 c1 == Branch x2 c2 = x1 == x2 && c1 == c2 Note the `forall b. Eq b =>` in the constraint for this instance, which is necessary in order for the instance to be obviously terminating. There are *many* other motivations for this feature, dating back over a decade. Particularly pressing might be the fact that this feature will allow us to put `join` in the Monad type class, currently impossible due to the way roles work. See https://ryanglscott.github.io/2018/03/04/how-quantifiedconstraints-can-let-… for the details (which are not necessary in order to evaluate this proposal -- merely good motivation). The proposal introduces -XQuantfiedConstraints, which will enable the new feature, though -XExplicitForAll will also be necessary if you wish to write a `forall` explicitly (as you likely will). There are some subtleties of the typing rules, but it all basically behaves as you would expect. Quantified constraints may induce a situation where GHC must choose one of two potential routes toward proving a goal; when this happens, the program is rejected (even if one or more of the routes would have been successful). Note that quantified constraints cannot introduce incoherence, as they do not create new instances. Simon has already implemented this feature on a branch, and as I understand it, it's working swimmingly. Recommendation: accept. This feature has been wanted for a long time, is a natural extension of features GHC already has (roles, higher-rank types), and has been implemented cleanly. As usual, I will take silence as agreement. I look forward to reading your comments. Thanks, Richard

3 3

Please Review: forall {k}, Shepherd: Iavor Diatchki
by Joachim Breitner 18 Apr '18

18 Apr '18

Dear Committee, this is your secretary speaking: Explicit specificity (forall {k},) has been proposed by Richard: https://github.com/ghc-proposals/ghc-proposals/pull/99 I propose Iavor Diatchki as the shepherd. Iavor, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Re: [ghc-steering-committee] Proposal: Embrace Type in Type (#83)
by Simon Peyton Jones 17 Apr '18

17 Apr '18

I think we all agree that we should collapse -XPolyKinds and -XTypeInType. The only issue is what to do about *. No solution is perfect: let's get this decided! The status quo is terrible! * With -XTypeInType, - '*' means Type iff '*' is imported from Data.Kind - '*' has no special meaning otherwise; that is, it's an ordinary infix operator, and is used as such in TypeLits - Ambiguity error if it is in scope two ways) * Without -XTypeInType - '*' means Type iff it is used in a context that syntactically means "this is a kind" - '*' has no special meaning otherwise That is, the meaning of '*' depends both on the extension flags -- and moreover on a flag whose primary purpose is quite separate -- AND depends (in some cases) on lexical scope or (in other cases) on syntactic context. This is a ridiculous design. The simplest thing to do is to say * The meaning of '*' is controlled by a flag, -XStarIsType, that has no other purpose * -XStarIsType is on by default. (Perhaps: switched off by -XTypeOperators.) * 'Type' is exported by Data.Type (or whatever) and is always available as an alternative to '*'. * When -XStarIsType is on, we print '*' in error messages whenever possible. That is simple and explicable. Moreover the on-by-default rule means that most existing prams that use PolyKinds will continue to work unchanged. In effect -XStarIsType is roughly the delta between -XPolyKinds and -XTypeInType. Once that is in place we can think about future policy. For example - Leave it alone - Announce that -XStarIsType will move to off-by-default in a specified future GHC XX.YY, and emit deprecation messages for three previous releases But let's get this done, one way or another. Simon | -----Original Message----- | From: ghc-steering-committee <ghc-steering-committee- | bounces(a)haskell.org> On Behalf Of Joachim Breitner | Sent: 16 April 2018 18:46 | To: ghc-steering-committee(a)haskell.org | Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type | | Hi, | | Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg: | > An alternative that hasn't been suggested so far is to have | > -XStarIsType control the pretty-printer as well as the parser. Simon | > PJ and I discussed this this morning, thinking it was a good idea. | > Upon further consideration, my preference would be to bite the | bullet | > and just switch to printing Type always, but I'm not really against | > the print-*-with-XStarIsType idea. | | I’m with Simon here. We have, I believe, precedence where error | messages are affected by the language extension in scope, so this | might satisfy the principle of least surprise, and also cause the | least contention among our users. | | We can still apply this rule when `-XNoStarIsType`: | | > One slightly separate question is what to print. The proposal | > currently suggests to print Type. There was concern in this thread | > that it would be printed fully-qualified, but I like Joachim's | > suggestion in the last known email in this thread to special-case | > printing of Type; even if it's not imported, it would print as Type, | > not Data.Kind.Type. (Unless some other Type were in scope.) It is | also | > easy to teach GHC to print a bespoke warning when a user writes Type | > when it is out of scope, telling them to import Data.Kind. | | The proposal currently does not state which modules export Type. I can | infer from the text that it is Data.Kind, but this could be made | explicit. Also, the proposal should state whether it is re-exported | from Prelude or not (I assume it is not). | | Cheers, | Joachim | | -- | Joachim Breitner | mail(a)joachim-breitner.de | http://www.joachim-breitner.de/

1 0

Please Review: Resurrect PatternSignatures, Shepherd: Christopher Allen
by Joachim Breitner 16 Apr '18

16 Apr '18

Dear Committee, this is your secretary speaking: Resurrect PatternSignatures has been proposed by me: https://github.com/ghc-proposals/ghc-proposals/pull/119 I propose Chris Allen as the shepherd. Chris, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

DH quantifiers (#102), Recommendation: accept
by Joachim Breitner 16 Apr '18

16 Apr '18

Dear Committee, this is your secretary speaking: Dependent Haskell quantifiers were proposed, by Richard. https://github.com/ghc-proposals/ghc-proposals/pull/102 rendered at https://github.com/goldfirere/ghc-proposals/blob/pi/proposals/0000-pi.rst I’ll shepherd that myself. This proposal defines and reserves the syntax for the quantifiers that eventually Dependent Haskell will need, and allows their use where it makes sense already (e.g. in Kinds). The quantifier are: forall a. forall a '. forall a -> forall a '-> foreach a. foreach a '. foreach a -> foreach a '-> ty => ty '=> ty -> ty '-> It addresses the interaction with warning (e.g. -Wcompat). It looks well-thought-through, one might infer that the authors wrote a thesis about this stuff. There is some syntactic bikeshedding possible; for example the proposal proposes "foreach" instead of "pi" (the latter would make "pi" a keyword, which would be unfortunate for those who deal with circles). If someone has better ideas, in particular about the use of ' to denote matchable arrows, we still have time to suggest them. I recommend to accept this proposal in the current form or with further refinements to the syntax, if we can come up with them. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 10

Plugin recompilation avoidance interface (#108)
by Ben Gamari 16 Apr '18

16 Apr '18

Hello everyone, I have been assigned as the shepard for proposal #108. This proposes a change in GHC's plugin interface allowing plugins greater control over recompilation, significantly improving compilation times for projects relying on compiler plugins. Summary: The proposal suggests that the existing fields of the `ghc` package's Plugin.Plugin type be wrapped with a type capturing a function computing the plugin's recompilation desired behavior, data PluginRecompile = ForceRecompile | NoForceRecompile | MaybeRecompile Fingerprint GHC can then use this recompilation information to decide whether evaluating the plugin (and consequently invalidating any existing compilation artifacts) is necessary. Opinion & recommendation: The proposal addresses a long-standing limitation (#7414) of the GHC plugin interface which has become increasingly visible to users in recent years. While the particular approach proposed breaks existing plugin users, it is expressive enough to allow GHC to perform more aggressive recompilation avoidance in the future [1]. Moreover, the smart constructors proposed should make for a reasonably smooth migration path. Given that the plugins appears to have buy-in from a few notable plugin authors, I recommend that we accept this proposal. Cheers, - Ben

5 12