- ghc-steering-committee

Please review: or patterns, Shepherd: Manuel Chakravarty
by Joachim Breitner 19 Aug '17

19 Aug '17

Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/43 was brought before the committee, by Ömer Sinan Ağacan. I propose Manuel Chakravarty 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 about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Proposal format ambiguity
by David Feuer 08 Aug '17

08 Aug '17

The README and proposal template share an error. In the README: > Proposed Change Specification: > [...] > how the proposed change addresses the original problem (perhaps referring back to the example) > > Effect and Interactions. Detail how the proposed change addresses the original problem raised in the motivation. [...] In the template: > Proposed Change Specification > [...] > how the proposed change addresses the original problem > [...] > Effect and Interactions > > Detail how the proposed change addresses the original problem raised in the motivation. In each case, it is unclear whether the way the proposal addresses the original problem should appear in the proposed change specification section or the effects and interactions section. Minor side note: the title of the first section has a typo, "propsoal". David Feuer

2 1

Status
by Joachim Breitner 03 Aug '17

03 Aug '17

Hi, since the last status update one new proposals has come up for deliberation, and no proposals were decided. Open at the moment are: NOUNPACK on function arguments https://github.com/ghc-proposals/ghc-proposals/pull/46 Shepherd: Simon Marlow Status: There was more discussion on GitHub, and @treeowl will have a look if the proposal text is reflecting all that discussion. Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Waiting for Ryan to make a recommendation. Explicit foralls proposal https://github.com/ghc-proposals/ghc-proposals/pull/55 Shepherd: Simon Peyton Jones Status: Waiting for Simon to make a recommendation. Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Waiting for Ryan to make a recommendation. Besides these, there are some proposals actively under discussion. You can always check them out at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no… Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review: Lazy unboxed tuples, Shepherd: Ryan Newton
by Joachim Breitner 11 Jul '17

11 Jul '17

Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/45 was brought before the committee, by our own Richard. I propose Ryan Newton as the Shepherd, just to rotate this role properly. Ryan, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 2

Status
by Joachim Breitner 11 Jul '17

11 Jul '17

Hi, it has been a while since I sent out a status. Since then, we have rejected the “Eval class” proposal, https://github.com/ghc-proposals/gh c-proposals/pull/27, and two new proposals are up for discussion. Open at the moment are: UNPACK on function arguments https://github.com/ghc-proposals/ghc-proposals/pull/46 Shepherd: Simon Marlow Status: There was more discussion on GitHub. I queried the author (@treeowl) if this needs more work or can go ahead. Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Just now asked the shepherd for a recommendation. Explicit foralls proposal https://github.com/ghc-proposals/ghc-proposals/pull/55 Shepherd: Simon Peyton Jones Status: Just now asked the shepherd for a recommendation. Besides these, there are some proposals actively under discussion. You can always check them out at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no… Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review: Explicit foralls proposal, Simon Peyton Jones
by Joachim Breitner 11 Jul '17

11 Jul '17

Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/55 was brought before the committee, again by our own Richard. I propose Simon Peyton Jones as the Shepherd, since he has commented on this proposal already. Simon, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Status
by Joachim Breitner 01 Jun '17

01 Jun '17

[Please do not reply to this mail discussing individual proposals. Instead, reply to the appropriate thread, or start a new one.] Hi, just another status update: We just rejected the instance force proposal. Open at the moment are: Eval class https://github.com/ghc-proposals/ghc-proposals/pull/27 Shepherd: Richard Status: This came back after being sent to the author for revision. We are waiting for Richard to make a new decision suggestion. UNPACK on function arguments https://github.com/ghc-proposals/ghc-proposals/pull/46 Shepherd: Simon Marlow Status: Awaiting a recommendation from Simon Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 2

GHC proposal #5
by David Feuer 30 May '17

30 May '17

GHC proposal #5 [*], which I drafted, was recently merged. I was asked to modify the proposal to restrict the type signatures of patterns and builders to be the same, except for their contexts. I would like to make one last plea to remove this restriction, unless there are fundamental reasons it cannot be done. The reasons are as follows. 1. Despite the restriction, it remains possible, at least in many cases, to achieve exactly the same effect, albeit in a manner that is considerably more difficult to read. For example, one could write the following (ill-advised) pattern: pattern Ha :: a ~ Int => Word -> a pattern Ha x <- (fromIntegral -> x) where Ha :: a ~ (Word -> Word) => Word -> a Ha x = (x +) which, after more thinking than one might wish to apply, turns out to mean pattern Ha :: Word -> Int pattern Ha x <- (fromIntegral -> x) where Ha :: Word -> Word -> Word Ha x = (x +) 2. It would be *extremely unpleasant* to make this trick work with RankNTypes, where such mismatched signatures seem likely to have the most practical value. For example, suppose I want to write import Control.Lens import Control.Lens.Reified pattern Package :: Lens s t a b -> ReifiedLens s t a b pattern Package f <- Lens f where Package :: ALens s t a b -> ReifiedLens s t a b Package f = Lens $ cloneLens f This convenience pattern would pack up an ALens into a ReifiedLens; when unpacked, I'd get back a full Lens (The type Lens s t a b subsumes the type ALens s t a b). Without being able to use those different type signatures, I'd have to write something like this monstrosity: import Control.Lens.Internal.Context -- additionally pattern Package :: c ~ Functor => (forall f. c f => LensLike f s t a b) -> ReifiedLens s t a b pattern Package f <- Lens f where Package :: c ~ ((~) (Pretext (->) a b)) => (forall f. c f => LensLike f s t a b) -> ReifiedLens s t a b Package f = Lens $ cloneLens f I pity the poor soul who has to try to reverse engineer what those signatures are supposed to mean! While it's certainly possible to implement the restricted version now and expand it later, that would add *yet another* PatternSynonyms change for users to hack around with CPP. I hope you'll reconsider that decision in light of these examples. Thank you for your time, David Feuer [*] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0005-b…

3 7

Proposal #23: instance force: rejected
by Manuel M T Chakravarty 24 May '17

24 May '17

Based on the feedback received on the ”instance force” proposal https://github.com/ghc-proposals/ghc-proposals/pull/23 I conclude that the committee has decided to reject that proposal in its current form. In summary, we agree that the proposal tries to address a real problem, namely (1) to add additional constraints to simplify diagnostics and type queries (especially for teaching) as well as (2) specify a local default for classes like ’IsString’. However, we don’t think that the proposed mechanism is the right one to address this problem, and we should try to find a better solution. In summary the power-to-weight ratio of the proposal is not sufficient; specifically, * Problem (1) might be solved better outside of the language (e.g., with a compiler option or similar); * Problem (2) only seems to be solved partially; and * there remain questions about details concerning the type system and import/exports. Manuel

1 0

Proposal: Reject #44 NoIfThenElse
by Iavor Diatchki 16 May '17

16 May '17

Hello, I'd like to propose that we reject that NoIfThenElse proposal (#44). In short, it suggests that we remove the syntactic sugar for `if-then-else` and leave to programmers to define their own version as a function. I think that this has virtually no benefits and many draw-backs, including breaking existing code, and making programs more difficult to read. Would there be any objections if I was to mark this as rejected, and close the request? -Iavor

5 6