May 2017 - ghc-steering-committee

GHC steering committee participation
by Atze Dijkstra 23 Oct '17

23 Oct '17

Dear committee members, as you may have noticed I have not actively participated in proposal reviewing. I can wrap this in a long or short story, but at the core lies lack of time combined with my role at Standard Chartered (SC) evolving in a direction less involved with GHC and Haskell language design/implementation than I originally thought it might be. Privately, outside of SC, I also see little time and energy left for committee activities. The work on proposals seems to have started actively and vigorously and I'd rather not be this silent non-contributing participant. I feel it is important to have somebody from what can likely be called the largest Haskell based industrial development group be in contact with and contribute to what by definition is an important tool for us. After some consultation with colleagues I found Roman Leshchinskiy (rleshchinskiy(a)gmail.com) to be willing to replace me in the committee. For most of the committee members I guess he is already known from the FP community so I leave further introduction up to himself. Within SC Roman is responsible for GHC related supporting infrastructure and as such is more than I am involved in and confronted with GHC intricacies, which places him at a better position to contribute to the GHC steering committee from an industrial perspective. I am aware that stepping down might cause inconvenience, but also feel that this better can be done now than later when the committee is already on farther on its way in dealing with proposals. I am also aware that it is not really up to me to decide what to do next after me stepping down, but I feel the proposed replacement by Roman is the best option from my perspective. all the best, Atze

7 11

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

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

06 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