- ghc-steering-committee

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

25 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 24 Apr '18

24 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 19 Apr '18

19 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 17 Apr '18

17 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

Source plugins (#107), Recommendation: accept
by Christopher Allen 14 Apr '18

14 Apr '18

Dear Committee, Chris Allen here! GHC source plugins were proposed by Boldizsár Németh. The PR discussing the proposal is here: https://github.com/ghc-proposals/ghc-proposals/pull/107 Rendered at: https://github.com/nboldi/ghc-proposals/blob/patch-4/proposal-source-plugin… This proposal suggests the extension of the existing tlugin support in GHC with plugins that are able to access and modify the representation of the Haskell syntax tree and its environment. This would allow tool developers to base their tools on GHC plugins. A version of the proposal is already implemented at: https://phabricator.haskell.org/D4342 My present main concern would be the issues with recompilation that the current patch introduces but that seems like a problem with an implementation rather than the proposal. That's an issue for the GHC devs themselves to sort out, as I understand it. It's not obvious to me that the unresolved questions could be answered with deliberation rather than implementation and exploration. I am far from an expert on GHC plugins but from what I've been able to read about them I don't see any blockers in this proposal as-written. I reached out to a couple of people that have hacked on or around GHC in the past and it seemed like they were most keen to find out what problems of theirs this proposal would solve. I didn't see any actual objections raised. I recommend we accept this proposal in the current form or with further elaboration at the author's option. However, my recommendation here defers to the experience of others on the committee who know more about the plugins API and the substance of this proposal. -- Chris Allen

4 3

Proposal #79 "Add a :kind!! command to ghci" — propose yes
by Manuel M T Chakravarty 10 Apr '18

10 Apr '18

We need to decide on the Proposal #79 ”Add a :kind!! command to ghci, to expand type families and type synonyms”: (rendered) https://github.com/alpmestan/ghc-proposals/blob/master/proposals/0000-kind-… (discussion) https://github.com/ghc-proposals/ghc-proposals/pull/79 I agree that this is useful functionality and it is a simple change to GHCi. There has been some discussion about the naming of this command, but TBH I didn’t find any of the alternatives more convincing than ”:kind!!”, so I’d suggest to stick with that. I favour accepting this proposal. Are there any dissenting opinions? Cheers, Manuel

4 5

Please Review: Qualified Constraints, Shepherd: Richard Eisenberg
by Joachim Breitner 06 Apr '18

06 Apr '18

Dear Committee, this is your secretary speaking: Qualified Constraints by Gert-Jan Bottu and SPJ https://github.com/ghc-proposals/ghc-proposals/pull/109 I propose Richard Eisenberg as the shepherd. Richard, 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