- ghc-steering-committee

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 25 May '17

25 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 17 May '17

17 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

Proposal #46: NOUNPACK pragmas for function arguments
by Simon Marlow 08 May '17

08 May '17

https://github.com/ghc-proposals/ghc-proposals/pull/46 I tentatively propose that we accept this proposal. Briefly, the proposal is to allow a NOUNPACK pragma in a *type signature* to indicate that a value should not be unpacked by the worker-wrapper transformation, e.g.: insertR :: Ord k => {-# NOUNPACK #-} k -> v -> Map k v -> Map k v insertR k v m = go k k v m where go :: Ord k => {-# NOUNPACK #-} k -> k -> v -> Map k v -> Map k v go kp k v m = ... The idea is that sometimes unpacking a strict argument leads to worse code because the repacking doesn't get simplified away, and it's hard for worker-wrapper to tell that up front. It's quite difficult for the programmer to avoid this problem currently - the one trick we have available is the `lazy` pseudo-function, but that's difficult to use for this purpose because you have to ensure that *all* uses of the argument are made lazy, and there can be collateral damage. It's the wrong tool to solve this problem, but it's the only tool we have. I've had this issue personally, and I've worked around it with `lazy`, but it's an ugly and brittle workaround, and something better is needed. If we assume that NOUNPACK can only occur on the left of an arrow (rather like UNPACK/NOUNPACK in a GADT signature), then it's a fairly straightforward extension, and just requires plumbing the information through to the demand analyser / worker-wrapper. The dual UNPACK annotation also makes sense, I think, although it's not part of this proposal. I can imagine it being a future extension. Drawbacks I see: - It doesn't let you say anything more detailed than just "no", e.g. you can't say "don't unpack the first field of the record" - It requires a type signature, which you wouldn't otherwise need. I suppose you could use PartialTypeSignatures. - It doesn't let you say anything about strictness, only unpacking. If a NOUNPACK argument is inferred by the demand analyser to be strict, callers can use call-by-value. Overall I don't see any fatal flaws and there are benefits. It's not a beautiful extension by any means, but I don't think it's expensive or complicated to implement. I suggest we accept it. Thoughts? Cheers Simon

2 1

Status
by Joachim Breitner 07 May '17

07 May '17

[Please do not reply to this mail discussing individual proposals. Instead, reply to the appropriate thread, or start a new one.] Hi, currently under discussion 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. Force Instance https://github.com/ghc-proposals/ghc-proposals/pull/23 Shepherd: Manuel Status: Manuel suggests rejection, which is generally agreed by the committee. Manuel, I believe you can go ahead and reject the proposal, ideally with a short rationale. UNPACK on function arguments https://github.com/ghc-proposals/ghc-proposals/pull/46 Shepherd: Simon Marlow Status: Awaiting a recommendation from Simon Also still TODO (for Ben): Add @rleshchinskiy to the GitHub organization and remove @atzedijkstra https://github.com/orgs/ghc-proposals/people (or make me an owner there). Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Wrapping up Constructor Synonyms and Pattern Synonym Signatures
by Christopher Allen 28 Apr '17

28 Apr '17

Thank you to those of you that replied. I'd like to preserve the syntactic distinction that construction synonyms eliminates. Your statements have shifted me to a reject on https://github.com/ghc-proposals/ghc-proposals/pull/41 If no one has objections, I'd like to move to a reject as I think enough time has elapsed that it's unlikely to get any defenders. Speak up if you feel something was missed. Regarding https://github.com/ghc-proposals/ghc-proposals/pull/42 Summarizing peoples' replies so far: Joachim: In favor, as long as :i does the right thing. Seems under-specified, suggested the following possible relationships between signature of the pattern and the constructor: * May not differ in anything but the constraints. * Must have the same return type. * Must have the same outer type constructor in their return type. * No relation. Roman: In favor of this proposal under the "May not differ in anything but the constraints" policy and against it under any of the other three. Simon PJ: In favor of #42 alone, but no holes. Agrees with Roman that that type of the constructor should be the same as that of the pattern. Simon Marlow: I believe the statement was in favor of #42 contra #41, but I didn't get a sense of how strongly or how Simon felt about the particulars. I agree with and want to highlight Roman's point regarding, >A looser relationship between the constructor function and the pattern makes code significantly harder to read and the proposal doesn't include any justification for such a looser relationship so I would go with the strongest requirement possible. It seems to me like the respondents so far are in favor of #42, but want the strongest variant. I'd like to move to accept #42 with the "May not differ in anything but the constraints" variant. Any objections? Thank you Joachim for the status update last week. Thanks you for your time everyone, Chris Allen

6 8

Proposal #23: instance force
by Manuel M T Chakravarty 28 Apr '17

28 Apr '17

We need to decide whether we like to accept the ”instance force" proposal: https://github.com/ghc-proposals/ghc-proposals/pull/23 While I understand and am in favour of the motivation behind the proposal, I like to propose to reject the proposal in its current form. My reasons are the following: * The proposal is an ad hoc approach to adding additional type constraints to qualified types involving a specific type class. * I am against adding the proposed ”instance force” declaration form as its *main* motivation is to simplify error messages and type signatures printed by GHCi — i.e., it is of a diagnostic and informative nature. * Something like that does IMHO not belong into the language, but needs to be part of the configuration of the compilation system. In other words, it ought to be a, e.g., compiler option or a language pragma, but not a declaration form. In summary, I’d like to suggest to find an alternative means to get GHC to add the additional constraints to simplify diagnostics and type queries without encumbering the language itself. Cheers, Manuel

4 5