- ghc-steering-committee

Please Review: Array resizing primitives (#121), Shepherd: Simon Marlow
by Joachim Breitner 01 May '18

01 May '18

Dear Committee, this is your secretary speaking: Array resizing primitives have been proposed by David Feuer: https://github.com/ghc-proposals/ghc-proposals/pull/121 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

Re: [ghc-steering-committee] Discussion on proposal #99: forall {k}
by Manuel M T Chakravarty 01 May '18

01 May '18

I assume, you meant to send this to ghc-steering-committee(a)haskell.org (in CC now) and not to the dev list. Manuel > 01.05.2018 02:12 Iavor Diatchki <iavor.diatchki(a)gmail.com>: > > Hello, > > As a shepherd for proposal #99, I'd like to kick off the discussion. The full proposal is available here: https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/propo… <https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/propo…> > > Summary: allows programmers to write `forall {x}` instead of `forall x` in type signatures. The meaning of the braces is that this parameter cannot be instantiated with an explicit type application and will always be inferred. The motivation is to shorten explicit type applications by skipping parameters that are known to be inferable, the common example being omitting the kinds in signatures with poly kinds. > > As I understand it, the main motivation for this proposals is to give programmers more flexibility when instantiating type variables, with a less noisy syntax. While the proposed solution might work in some situations, I am unconvinced that it is the best way to address the issue in general, for the following reasons: > > 1. It requires that programmers commit at declaration time about which arguments will be inferred, and which may be inferred or specified. While in some cases this may be an easy decision to make, in many cases this really is a decision which should be made at the use site of a function (e.g., I'd like to provide argument X, but would like GHC to infer argument Y). > > 2. It still requires that programmers instantiate arguments in a fixed order, which is sometimes dictated by the structure of the type itslef. Here is, for example, what the proposal suggests to do if you want to provide type before a kind: > > typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a > > While technically this is not wrong, it is not exactly elegant. > > I think that we should reject this proposal, and try to come up with a more comprehensive solution to the problem. > > One alternative design is to allow programmers to instantiate type variables by name. This is much more flexible as it allows programmers to instantiate whichever variables they want, and in whatever order. We've been doing this in Cryptol for a long time, and it seems to work really well. > > -Iavor > > > > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Please Review: ExtraCommas (#87), Shepherd: Chris Allen
by Joachim Breitner 01 May '18

01 May '18

Dear Committee, this is your secretary speaking: ExtraCommas has been proposed by Andrew Martin: https://github.com/ghc-proposals/ghc-proposals/pull/112 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 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/

3 2

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

29 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 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 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