February 2019 - ghc-steering-committee

Discussion on #155 Type Variable in Labmdas
by Iavor Diatchki 09 May '19

09 May '19

Hello, let's get the discussion going about proposal #155 ( https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000… ). Summary: the idea is pretty simple: allow functions to name their type arguments explicitly, so that they can be used in type signatures within the function's definition. The notation for a type argument is `@a`, and such type arguments can be used only when functions have an explicit type signature (technically, when GHC is doing "checking" rather then "inference"). This proposal provides an alternative to "ScopedTypeVariables" to refer to type parameters, which I think is a step in the right direction, as using the `forall` to introduce type variables always felt a bit hacky to me (now, there's a technical argument :) I am a bit concerned with the notation though: in other places where we use `@a`, (e.g., #126 type application in patterns, and TypeApplications) the `a` is a type, while in this use it must be a variable. I wonder if this punning might be confusing. I don't really have an alternative suggestion though. What does everyone else thing? -Iavor

7 26

[Proposal] #175: Lift.liftTyped (recommendation: accept)
by Ben Gamari 02 May '19

02 May '19

Hi everyone, I have been asked to Shepard #175, which proposes to add a `liftTyped` method to the `Lift` typeclass used to lift Haskell values into Template Haskell splices. Currently the `Lift` typeclass provides no guarantee of type-safety, even when used in a Typed Template Haskell context. The proposal resolves this limitation by adding a typed lifting operation to the `Lift` class: class Lift t where lift :: t -> Q Exp liftTyped :: t -> Q (TExp t) While this addition will break manually-written `Lift` instances, we recommended that users derive such instances for quite a while now, so it is not expected that the breakage will be wide-spread. In light of this, I recommend that we accept this proposal. Given that we will likely want to get this in to 8.8, I suggest that we limit the discussion to a week unless there is dissent. Cheers, - Ben

6 19

Please review #176: SCC Parsing, Shepherd: Simon M
by Joachim Breitner 17 Apr '19

17 Apr '19

Dear Committee, this is your secretary speaking: Meaning-preserving parsing rules for SCC annotations has been proposed by Vladislav Zavialov: https://github.com/ghc-proposals/ghc-proposals/pull/176 https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-… I propose Simon Marlow as the shepherd (he already glimpsed at it, so hopefully already has an opinion.) 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 -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

8 19

Please review #209: Levity Polymorphic Lift, Shepherd: Eric Seidel
by Joachim Breitner 27 Feb '19

27 Feb '19

Dear Committee, this is your secretary speaking: Levity polymorphic lift has been proposed by Alec Theiault https://github.com/ghc-proposals/ghc-proposals/pull/209 https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/p… I propose Erid Seidel as the shepherd. 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 -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

[Proposal] #193: Make `forall` a keyword in type (recommendation: accept)
by Eric Seidel 14 Feb '19

14 Feb '19

This proposal suggests making `forall` a keyword at the type-level. `forall` is currently only a keyword when `-XExplicitForAll` is enabled. This change would avoid a potentially confusing situation where the meaning of a type can change based on which extensions are enabled. For example, ``` f2 :: forall a -> a -> a ``` with no extensions, the `forall a` would be interpreted as two regular type variables. But if we enable the upcoming "visible dependent quantification" extension (I assume there's an extension involved here somewhere, the proposal doesn't say), the `forall a` would be interpreted as a *single* dependently quantified type variable `a`. The only concerns are that this change could break existing programs, and that it moves us further away from the standard. I'd be very suspicious of any programs that used `forall` as a type variable, as that's just ripe for confusion. And it's a very small step away from the standard, so I don't think that should stand in the proposal's way either. I recommend we accept the proposal.

3 4

Proposal #167 (Deprecated Entities): Request for comments
by Vitaly Bragilevsky 08 Feb '19

08 Feb '19

Dear Committee, I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/000…) It is proposed to extend DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. Simon suggested another alternative to make DEPRECATED pragmas positional (in consistency with the deprecating modules). I like the positional alternative more, as it enables more fine-grained control over deprecated entities and can be extended to deprecating unnamed entities (like type class instances). It seems the author is okay with rewriting the proposal, but the current proposal is already implemented. So, the question is: do we want it quick or good? I am not ready to answer this question and come up with the recommendation on the proposal yet. Please, comment on the following issues: a) which form of the DEPRECATED pragma you prefer, b) do you see any potential drawbacks of the positional form, c) are there any caveats with deprecating instances. Your comments are very welcome either here or on GitHub ( https://github.com/ghc-proposals/ghc-proposals/pull/167) Thanks, Vitaly

6 11

Please review #155: Type Variable in Lambdas, Shepherd: Iavor
by Joachim Breitner 05 Feb '19

05 Feb '19

Dear Committee, this is your secretary speaking: Richard wants to bind Type variables in lambda.: https://github.com/ghc-proposals/ghc-proposals/pull/155 https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000… I propose Iavor Diatchki the shepherd. 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 -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #193: forall keyword, Shepherd: Eric
by Joachim Breitner 04 Feb '19

04 Feb '19

Dear Committee, this is your secretary speaking: make `forall` a keyword proposed by Richard: https://github.com/ghc-proposals/ghc-proposals/pull/193 https://github.com/goldfirere/ghc-proposals/blob/forall-keyword/proposals/0… I propose Eris Seidel as the shepherd. 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 -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #203: PtrRep, Shepherd: Simon PJ
by Joachim Breitner 03 Feb '19

03 Feb '19

Dear Committee, this is your secretary speaking: PtrRep has been proposed by Andrew Martin: https://github.com/ghc-proposals/ghc-proposals/pull/203 https://github.com/andrewthad/ghc-proposals/blob/pointer_rep/proposals/0000… I propose Simon PJ as the shepherd (he already glimpsed at it, so hopefully already has an opinion.) 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 -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0