January 2019 - ghc-steering-committee

[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

Status
by Joachim Breitner 26 Jan '19

26 Jan '19

Dear committee, another quiet month. There are a few proposals that are desperately waiting for action from Manuel, Ben and Chris. Here is what happened: * were asked to review these proposals: -none- * got a recommendation from shepherds about: #158 Add setField to HasField (rec: accept) * decided about the following proposals -none- (But new, unsubmitted proposals are on the horizon.) We currently have to act on the following 6 proposals, down one because the Or pattern proposal got withdrawn. liftTyped https://github.com/ghc-proposals/ghc-proposals/pull/175 Shepherd: Ben Status: Acceptance recommended, more discussion happening, it seems. record-set-field proposal https://github.com/ghc-proposals/ghc-proposals/pull/158 Shepherd: Yav Status: Acceptance recommended, discussion about fundeps vs. tf. Type annotated quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Shepherd: Manuel Status: Still waiting for recommendation. Manuel? Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Status: Still waiting for recommendation. This is pretty old! ExtraCommas https://github.com/ghc-proposals/ghc-proposals/pull/87 Shepherd: Chris Recommendation: accept Status: Met with some reservation. Chris, please pick this up again. Bundling patterns with synonyms https://github.com/ghc-proposals/ghc-proposals/pull/28 Shepherd: Chris Recommendation: reject Status: Chris, you still need to write the rejection reasons to the ticket. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee(a)haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

2 1

Bundling patterns with type synonyms (#28)
by Christopher Allen 26 Jan '19

26 Jan '19

The proposal I'm reviewing is: Bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski https://github.com/ghc-proposals/ghc-proposals/pull/28 Having reviewed the proposal and gone through some of the GHC Trac history, I think we should accept this proposal. There are a couple of open questions, ambiguities, and potential downsides but the overall complexity of the proposal doesn't cause me great concern. Cheers, Chris Allen

5 11

Discussion for #158 "Add `setFild` to `HasField`"
by Iavor Diatchki 22 Jan '19

22 Jan '19

Hello, let's start the discussion on proposal #158. After some discussion on the pull request the proposal was changed, so that instead of adding another method, it now proposes to remove the existing method `getField`, and add a new method `hasField`, which allows to both access and change the value of a field. After the proposal the class would look like this -- `x` is the name of the field, `r` is the type of the record, `a` is the type of the field class HasField x r a | x r -> a where hasField :: r -> (a -> r, a) In addition, we'd provide two functions `getField` and `setField` which are defined in terms of `hasField`. The proposal may break existing code, if it defines manual instances of `HasField`, however, code that just uses the functionality will continue working as before. `HasField` is relatively new, and there aren't many reasons to define custom instances of it, so it is expected that breaking code would not be a big issue. This seems like a reasonably simple change, that adds new functionality, so I recommend that we accept the change. -Iavor

3 6

Please review #167: Deprecated Entities, Shepherd: Vitaly
by Joachim Breitner 21 Jan '19

21 Jan '19

Dear Committee, this is your secretary speaking: Adding namespaces to DEPRECATED has been proposed by Alex Dudarenko: https://github.com/ghc-proposals/ghc-proposals/pull/167 https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/000… I propose Vitaly Bragilevsky 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