July 2018 - ghc-steering-committee

Deprecating Exports (#134); Recommendation: accept
by Joachim Breitner 14 Jul '18

14 Jul '18

Hi, alanasp has proposed a Deprecating Exports mechanism: https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating… The gist is explained by this: module Data.List ( ... {-# DEPRECATE lines "Exported from Data.String instead" #-} , lines ...t ) where i.e. DEPRECATE pragmas in export lists cause warning when some other module uses the deprecated symbol when it is imported (only) via some deprecated export. This is a GSOC 2018 project, mentored by Matthew Pickering and Erik de Castro Lopo. The feature has a clear use-case, is self-contained and David Feuer (the containers maintainer) has already confirmed that there is a real demand for this. I suggest acceptance! As always, I will understand silence as tactic consensus. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 9

Please Review: Remove * syntax (#143), Shepherd: Ben Gamari
by Joachim Breitner 14 Jul '18

14 Jul '18

Dear Committee, this is your secretary speaking: Remove * kind syntax (#143) by Vladislav Zavialov was proposed. https://github.com/ghc-proposals/ghc-proposals/pull/143 I propose Ben Gamari as the shepherd, because he probably has the stuff paged in from shepherding #146 Ben, 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

Replace atomicModifyMutVar# (#149), recommendation: accept
by Simon Marlow 11 Jul '18

11 Jul '18

https://github.com/ghc-proposals/ghc-proposals/pull/149 This proposal is essentially an optimisation to the atomicModifyMutVar# primitive. I won't repeat the details here, but it amounts to moving one of the thunks produced by atomicModifyMutVar# out of the primop and into the atomicModifyIORef wrapper. The advantage is that in the case of the strict version of the wrapper, atomicModifyIORef', this extra thunk is eliminated entirely, rather than being created by the primop and then immediately evaluated by the wrapper. I propose we accept the proposal to add the new primop in section 2.1, along with the straightforward additions proposed in sections 2.2 and 2.3. (the old primop will be removed, but can be defined in GHC.Exts as a wrapper around the new primop for backwards compat) However, the additions to the Data.IORef library should be considered by the libraries committee separately. (there are naming issues to be resolved in particular). Cheers Simon

4 4

Remove TypeOperators => NoStarIsType "migration" (#146); Recommendation: accept
by Ben Gamari 10 Jul '18

10 Jul '18

Hi everyone, We are being asked to consider pull request #146. This proposal is an amendment to the accepted Proposal 0020 [1], removing a migration mechanism which was found in practice to hurt more than help. Specifically, proposal 0020 currently specifies a migration period during which the -XNoStarIsType extension (which proposal 0020 introduces) will be implied by -XTypeOperators. The motivation for this was to ease the transition for packages which use * as a binary type operator. In practice it turned out that a significant number of packages are broken by this migration mechanism. Specifically, many packages use * in kind signatures while also enabling TypeOperators. The proposed amendment removes TypeOperator's implication of NoStarIsType. To be clear, this is ultimately a trade-off between optimising for users of (*) as a binary operator and users of * ~ Type. It just so happens that there are far more of the latter. Consequently, my recommendation is to accept the modified proposal. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/83

5 7

Solicitation for a new member
by Joachim Breitner 09 Jul '18

09 Jul '18

Dear Committee, Ryan Newton has expressed interest in being rotated out of the committee. I spoke to the Simons, and they indicate we should ask for public nominations. Here is a draft of a mail I’d send to the usual mailing lists. Please comment. ========================== Dear community, the GHC Steering committee is seeking nomination for a new member, and ask for self-nominations. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC Our processes are described in the README in https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * make constructive comments and improvements, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. Particular pluses that we look for are * candidates who have been in the community for some time, and/or * who have expertise in language design and implementation in related language, which they can share with us. The committee work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. Please keep that in mind if your email inbox is already flowing over. There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. I therefore explicitly invite “conservative” members of the community to join the committee. The GHC developers themselves are nicely represented already. Having hacked on GHC is not a requirement. To nominate yourself, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until July 20th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. You cannot nominate others. But if you know of anyone else you’d think should be on the committee, please do encourage them, or talk to us and we can encourage them. On behalf of the committee, Joachim Breitner ========================== Note worth discussing: * I see no point in non-self-nominations. We can only have members that want to do this. * Do we want to encourage “conservative” members? Is that the right wording? (I see the committee a bit as a flood gate that protects against premature and not-worth-it changes. We are doing a good job of that – most of my proposals get rejected ;-) – but I think it would not hurt to explicitly keep it that way. * One could consider public nominations and deliberations, but I feel that a public discussion of who we think is the “best” is not very nice. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 7

Please Review: Replace atomicModifyMutVar# (#149), Shepherd: Simon Marlow
by Joachim Breitner 03 Jul '18

03 Jul '18

Dear Committee, this is your secretary speaking: Replace atomicModifyMutVar# (#149) by David Feuer was proposed. https://github.com/ghc-proposals/ghc-proposals/pull/149 I propose Simon Marlow as the shepherd, because this is RTS-land. Simon, 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

Re: [ghc-steering-committee] Discussion on proposal #99: forall {k}
by Richard Eisenberg 02 Jul '18

02 Jul '18

Yes -- it's a property of the type. This aspect wasn't highlighted in the original proposal because it's not a change. Types *already* have this inferred/specified distinction (and have since GHC 8.0), but users can't directly access the feature. This proposal is all about -- and only about -- concrete syntax. Richard

2 1

Re: [ghc-steering-committee] Discussion on proposal #99: forall {k}
by Simon Peyton Jones 02 Jul '18

02 Jul '18

It’s already present in the implementation, but it’s not already present in any explicitly-stated language proposal. So this proposal might be a good opportunity to fix that deficiency. S From: Richard Eisenberg <rae(a)cs.brynmawr.edu> Sent: 02 July 2018 13:23 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: Iavor Diatchki <iavor.diatchki(a)gmail.com>; ghc-steering-committee(a)haskell.org; Joachim Breitner <mail(a)joachim-breitner.de> Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k} Yes -- it's a property of the type. This aspect wasn't highlighted in the original proposal because it's not a change. Types *already* have this inferred/specified distinction (and have since GHC 8.0), but users can't directly access the feature. This proposal is all about -- and only about -- concrete syntax. Richard On Jul 2, 2018, at 4:49 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: It really is not quite clear if the specificity is a property of the type itself, or the thing that has that type. I think Richard has clarified now, right? It’s a property of a type. Simon From: Iavor Diatchki <iavor.diatchki(a)gmail.com<mailto:iavor.diatchki@gmail.com>> Sent: 29 June 2018 19:26 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Cc: Richard Eisenberg <rae(a)cs.brynmawr.edu<mailto:rae@cs.brynmawr.edu>>; ghc-steering-committee(a)haskell.org<mailto:ghc-steering-committee@haskell.org>; Joachim Breitner <mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de>> Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k} I am supportive of accepting the proposal, but I think that we should address the point raised by Joachim on the the git-hub thread first (https://github.com/ghc-proposals/ghc-proposals/pull/99#issuecomment-4010609…<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>). It really is not quite clear if the specificity is a property of the type itself, or the thing that has that type. On Thu, Jun 28, 2018 at 1:07 AM Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: I’m keen on this proposal. I am very keen to be able to express in a type or kind signature everything needful to use the value (or type constructor). The proposal gives an example at the term level. It’d be strengthened by an example at the type level. Eg type T1 :: forall {k}. (k->Type) -> k -> Type data T1 f a = MkT (f a) type T2 :: forall k. (k->Type) -> k -> Type data T2 f (a::k) = MkT2 (f a) Here T1 has an inferred kind variable, mentioned nowhere in the declaration. The kind signature (which I have written as if it were code, which is the subject of a separate proposal) is inferred as shown. T2 mentions k, so its kind signature looks a bit different. What’s the difference? It’s exactly in explicit kind application. You can write (T1 @Type Maybe Int), but T2 can’t have that explicit kind argument. The whole business of Required/Specified/Inferred is more complicated than I like, but if we have it (which we do right now) we should allow the programmer to specify exactly what they mean. (An alternative is to abolish the Specified/Inferred distinction, but that carries significant costs of its own and no one is proposing it.) Let’s accept! Simon From: Richard Eisenberg <rae(a)cs.brynmawr.edu<mailto:rae@cs.brynmawr.edu>> Sent: 28 June 2018 05:45 To: Iavor Diatchki <iavor.diatchki(a)gmail.com<mailto:iavor.diatchki@gmail.com>> Cc: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>>; ghc-steering-committee(a)haskell.org<mailto:ghc-steering-committee@haskell.org>; Joachim Breitner <mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de>> Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k} But we morally *do* have explicit kind application. See accepted proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0015-t…<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> So the only reason that we don't have it is that GHC hasn't caught up to its specification. (I have a student working on this now.) The reason that T2 and T3 are different here is that T2 mentions the k in the type declaration, while T3 mentions it only in the constructor declaration. Richard On Jun 26, 2018, at 6:52 PM, Iavor Diatchki <iavor.diatchki(a)gmail.com<mailto:iavor.diatchki@gmail.com>> wrote: Hello, thanks for the revisions---I read through the new version, and I think I almost understand the plan. I would say that for this proposal it makes more sense to just deal with explicit specificities at the value level, and never have the curly braces in type constructors. Since we don't have an explicit kind application at the type level (e.g., we can't write `Proxy @Type`), I don't think it really makes sense to add the braces to type constructors. If we ever implemented THAT feature, then we can discuss which declarations should have explicit and which should have implicit parameters. In the current set of examples, I find it odd that `T2` does not have braces, but `T3` does. -Iavor On Wed, Jun 20, 2018 at 2:15 PM Richard Eisenberg <rae(a)cs.brynmawr.edu<mailto:rae@cs.brynmawr.edu>> wrote: I have posted the new proposal, at https://github.com/ghc-proposals/ghc-proposals/pull/148<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> I've also updated #99 to clarify where the new syntax is allowed. For Iavor's examples: data T1 a = C1 a type T1 :: Type -> Type C1 :: forall a. a -> T1 a data T2 (a :: k) = C2 { f2 :: Proxy a } type T2 :: forall k. k -> Type C2 :: forall k (a :: k). Proxy a -> T2 a f2 :: forall k (a :: k). T2 a -> Proxy a data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a type T3 :: forall {k}. k -> Type C3 :: forall k (a :: k). Proxy a -> T3 a data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a type T4 :: forall {k}. k -> Type C4 :: forall {k} (a :: k). Proxy a -> T3 a data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a Rejected, as k is used dependently but is not lexically dependent. (This is no change.) It we have > data T5 k (a :: k) where C5 :: forall k (a :: k). Proxy a -> T5 k a we would get type T5 :: forall k -> k -> Type C5 :: forall k (a :: k). Proxy a -> T5 k a data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a Rejected, like T6. If we revise to: > data T6 k (a :: k) where C6 :: forall {k} (a::k). Proxy a -> T6 k a we get type T6 :: forall k -> k -> Type C6 :: forall {k} (a::k). Proxy a -> T6 k a I've updated the proposal itself to include these examples. Does this help to clarify? Richard On May 25, 2018, at 1:56 PM, Iavor Diatchki <iavor.diatchki(a)gmail.com<mailto:iavor.diatchki@gmail.com>> wrote: Hello, well, I thought that Richard was going to write a new proposal based on the feedback here, but it sounds like he is planning to revise #99, and then write a separate new one. I guess we should discuss the proposal again once the changes are in. I would encourage Richard to add some text and examples to clarify exactly what's in the proposal and what's not, and how things are supposed to work. Here are some examples, for which it would be illuminating (to me) to see the types/kinds of all names introduced. data T1 a = C1 a data T2 (a :: k) = C2 { f2 :: Proxy a } data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a -Iavor On Fri, May 25, 2018 at 2:02 AM Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: I’m keen to get #99 into GHC in some form. My motivation (which could be a fourth bullet in the proposal) is that it should be possible for a programmer to write a fully-explicit type signature for anything GHC can infer. But currently we can’t. For typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it down. based on the discussion so far, it seems that #99 in its current form might not be exactly what we want Can you summarise the reasons it might not be exactly what we want? Simon From: ghc-steering-committee <ghc-steering-committee-bounces(a)haskell.org<mailto:ghc-steering-committee-bounces@haskell.org>> On Behalf Of Richard Eisenberg Sent: 24 May 2018 21:17 To: Iavor Diatchki <iavor.diatchki(a)gmail.com<mailto:iavor.diatchki@gmail.com>> Cc: ghc-steering-committee(a)haskell.org<mailto:ghc-steering-committee@haskell.org>; Joachim Breitner <mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de>> Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k} I do plan on turning Joachim's recent suggestion into a separate proposal, and then to modify #99. But the modification would remove only the bit about classes, not the feature overall. I don't have time to do this now, though -- will do next week. Richard On May 24, 2018, at 1:54 PM, Iavor Diatchki <iavor.diatchki(a)gmail.com<mailto:iavor.diatchki@gmail.com>> wrote: Hello, based on the discussion so far, it seems that #99 in its current form might not be exactly what we want, so I'd say that we should reject it for the moment. Overall, I agree that it would be nice to come up with a consistent notation for things that are currently happening in GHC but we can't write, so perhaps we could revisit this with a revised proposal at a later time? -Iavor On Sat, May 5, 2018 at 8:48 PM Joachim Breitner <mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de>> wrote: Hi, Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg: > Joachim, you are always a fount of interesting ideas. > > > On May 2, 2018, at 2:51 PM, Joachim Breitner <mail@joachim-breitner > > .de> wrote: > > > > class C k (a : k) where meth :: a > > meth :: forall {k} a. C k a -> k -> Constraint > > I think this is brilliant. But not only for this proposal! Imagine > this: > > class Num a where > fromInteger :: Integer -> a > > fromInteger :: Integer -> forall a. Num a => a > > If we do that, then #129 is essentially solved, at no further cost to > anyone. (Note that in all Haskell98-style code, no one will ever be > able to notice the changed type of fromInteger.) > > This approach also allows for the possibility of reordering > quantified type variables for Haskell98-style constructors, if anyone > should want to do it. > > And it allows for updated types (including quantified variable > ordering, etc.) for record selectors. > > And it allows (maybe?) for giving good types to GADT record > selectors: > > data X a where > Foo :: { bar :: Int } -> X Int > Quux :: { bar :: Bool } -> X Bool > bar :: X a -> a > > GHC currently rejects the declaration for X, but it could be accepted > if only we could specify the correct type of bar. And now we can. I > don't particularly want to cook up the typing rules here, but I don't > think I'm totally crazy. > > GADT record selectors aside, the rule for these could be that the > top-level type signature must be equivalent w.r.t. the subtype > relation with the original type signature. That is, if the new > signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy > enough to check for. The implementation would probably do a little > worker/wrapper stunt. I smell a new proposal… what does this mean for #99? Will you want to revise it? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de> http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim…> _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee(a)haskell.org<mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee(a)haskell.org<mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

1 0

Re: [ghc-steering-committee] Discussion on proposal #99: forall {k}
by Simon Peyton Jones 02 Jul '18

02 Jul '18

[Redirecting to the steering committee] I argue for acceptance. * For me a compelling motivation is this: at the moment we can infer types and kinds that we cannot write down with an explicitly-quantified type signature. That seems all wrong to me: we should be able to write down any type you can infer. * The proposal adds notation. It does not add semantics. We already have the distinction between “inferred” and “specified” type variables. You might not like it, but it’s there in GHC. * If it wasn’t there already, I’d be happy to debate not adding it. * If you want to argue for removing the distinction, that would certainly render the current proposal moot. But that would take a GHC proposal – and there are good reasons for the status quo! * What is bad is to maintain the semantic distinction, but be unable to express it. That’s what we have right now, and it’s a bad thing. What is the distinction between “specified” and “inferred”? * Specified. f :: forall a. blah, or f :: a -> a. You may give a visible type argument at a call of f, but you do not have to. Thus (f x) or (f @type x). * Inferred. f :: t a -> t a. The type of f is really g :: forall {k} (t :: k -> *) (a :: k). t a -> t a Note that k does not appear at all in the signature; that’s why it is “inferred”. In GHC today you cannot supply an explicit kind argument for g, but you can supply explicit argument for t and a. So by all means make the case for abolishing the distinction, to render the present proposal moot. But I think it’s unreasonably simply to reject on the grounds of “please think of something better”. Simon From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Iavor Diatchki Sent: 30 April 2018 17:12 To: ghc-devs(a)haskell.org Subject: Discussion on proposal #99: forall {k} Hello, As a shepherd for proposal #99, I'd like to kick off the discussion. The full proposal is available here: https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/propo… Summary: allows programmers to write `forall {x}` instead of `forall x` in type signatures. The meaning of the braces is that this parameter cannot be instantiated with an explicit type application and will always be inferred. The motivation is to shorten explicit type applications by skipping parameters that are known to be inferable, the common example being omitting the kinds in signatures with poly kinds. As I understand it, the main motivation for this proposals is to give programmers more flexibility when instantiating type variables, with a less noisy syntax. While the proposed solution might work in some situations, I am unconvinced that it is the best way to address the issue in general, for the following reasons: 1. It requires that programmers commit at declaration time about which arguments will be inferred, and which may be inferred or specified. While in some cases this may be an easy decision to make, in many cases this really is a decision which should be made at the use site of a function (e.g., I'd like to provide argument X, but would like GHC to infer argument Y). 2. It still requires that programmers instantiate arguments in a fixed order, which is sometimes dictated by the structure of the type itslef. Here is, for example, what the proposal suggests to do if you want to provide type before a kind: typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a While technically this is not wrong, it is not exactly elegant. I think that we should reject this proposal, and try to come up with a more comprehensive solution to the problem. One alternative design is to allow programmers to instantiate type variables by name. This is much more flexible as it allows programmers to instantiate whichever variables they want, and in whatever order. We've been doing this in Cryptol for a long time, and it seems to work really well. -Iavor

4 22