From rae at cs.brynmawr.edu Mon Oct 1 01:08:38 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sun, 30 Sep 2018 21:08:38 -0400 Subject: [ghc-steering-committee] Bundling patterns with type synonyms (#28) In-Reply-To: References: <61FD037C-4A8F-45F2-A0E1-9010380F8029@cs.brynmawr.edu> <08573db359ccbefa07080c28884667d56bde207d.camel@joachim-breitner.de> Message-ID: I agree with rejecting. I think this should be part of a larger proposal to introduce modules. Thanks, Richard > On Sep 30, 2018, at 3:22 PM, Christopher Allen wrote: > > I think based on what transpired in this thread and on the GitHub PR, > the proposal should be rejected. My reasoning: > > - There was a more general way to solve the problem outlined by Simon. > - The complexity doesn't pay for itself, esp. given how particular the > problem it solves is. > > What do y'all think? > On Sat, Aug 4, 2018 at 10:35 AM Joachim Breitner > wrote: >> >> Hi, >> >> we have disagreement here. Chris, would you steer us towards consensus? >> >> Cheers, >> Joachim >> >> Am Samstag, den 23.06.2018, 23:19 -0400 schrieb Richard Eisenberg: >>> Agreed. Beyond my posted technical reservations, I believe that a better solution is out there. >>> >>> Richard >>> >>>> On Jun 23, 2018, at 1:00 PM, Joachim Breitner wrote: >>>> >>>> Hi, >>>> >>>> Am Mittwoch, den 13.06.2018, 18:18 -0500 schrieb Christopher Allen: >>>>> Bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski >>>>> >>>>> https://github.com/ghc-proposals/ghc-proposals/pull/28 >>>>> >>>>> >>>>> 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. >>>> >>>> I agree with Simon that might not take the language in the direction we >>>> want to take it. >>>> >>>> In fact, if we had PatternSynonyms and ExplicitNamespaces back when >>>> Haskell was first specified, we might not have the T(K) syntax at all, >>>> and just a flat, explicit list of names, possibly requiring explicit >>>> namespace qualifier to disambiguate? Things like deprecating exports >>>> would have been easier then… >>>> >>>> So while I follow the motivation of the proposal, and I don’t have >>>> concrete other solution to offer, I am inclined to reject it: The >>>> problem it is solving does not seem to be too urgent, and my gut >>>> feeling says that there might be something better down the road. >>>> >>>> Cheers, >>>> Joachim >>>> >>>> -- >>>> Joachim Breitner >>>> mail at joachim-breitner.de >>>> http://www.joachim-breitner.de/ >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From rae at cs.brynmawr.edu Mon Oct 1 01:57:59 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sun, 30 Sep 2018 21:57:59 -0400 Subject: [ghc-steering-committee] Proposal #170: Uppercase OverloadedLabels, rec: accept In-Reply-To: References: Message-ID: I'm on the fence. As you'll see on the GitHub trail, I wonder if this proposal doesn't go far enough. If we're going to generalize, let's go as far as we can. Richard > On Sep 30, 2018, at 3:16 PM, Vitaly Bragilevsky wrote: > > Hi all, > > As a shepherd to the proposal #170, Uppercase OverloadedLabels (https://github.com/ghc-proposals/ghc-proposals/pull/170 ) proposed by howtonotwin, I recommend acceptance. > > It is proposed to allow the string after # (with -XOverloadedLabels) to start uppercase thus looking like a constructor name in addition to a variable name as we have now. > > The proposal is clear, there are no known pitfalls. I suggest having two weeks for discussion. Silence is understood as an an agreement with this recommendation. > > Regards, > Vitaly > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Mon Oct 1 13:42:14 2018 From: eric at seidel.io (Eric Seidel) Date: Mon, 01 Oct 2018 09:42:14 -0400 Subject: [ghc-steering-committee] Proposal #170: Uppercase OverloadedLabels, rec: accept In-Reply-To: References: Message-ID: <1538401334.2308615.1526501608.3B98E39D@webmail.messagingengine.com> I share Richard's concern about missing an opportunity to generalize OverloadedLabels even further. But let's also not lose sight of the fact that the proposal as-is is very sensible! So, if we cannot form a consensus around an even more general OverloadedLabels, we should at least accept the current proposal. On Sun, Sep 30, 2018, at 21:57, Richard Eisenberg wrote: > I'm on the fence. As you'll see on the GitHub trail, I wonder if this > proposal doesn't go far enough. If we're going to generalize, let's go > as far as we can. > > Richard > > > On Sep 30, 2018, at 3:16 PM, Vitaly Bragilevsky wrote: > > > > Hi all, > > > > As a shepherd to the proposal #170, Uppercase OverloadedLabels (https://github.com/ghc-proposals/ghc-proposals/pull/170 ) proposed by howtonotwin, I recommend acceptance. > > > > It is proposed to allow the string after # (with -XOverloadedLabels) to start uppercase thus looking like a constructor name in addition to a variable name as we have now. > > > > The proposal is clear, there are no known pitfalls. I suggest having two weeks for discussion. Silence is understood as an an agreement with this recommendation. > > > > Regards, > > Vitaly > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Sat Oct 6 15:46:25 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 06 Oct 2018 08:46:25 -0700 Subject: [ghc-steering-committee] Please review #173: The dot type operator, Shepherd: Eric Seidel Message-ID: <515c81e4610acf85fe5cb2e78a69502674ac7208.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: The dot type operator, by Vladislav Zavialov, was proposed https://github.com/ghc-proposals/ghc-proposals/pull/173 I propose Eric Seidel 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 at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Tue Oct 9 17:44:26 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 09 Oct 2018 18:44:26 +0100 Subject: [ghc-steering-committee] Proposal #174: Lower precedence for {-# UNPACK #-}, rec: accept Message-ID: <268c3f6df5cd071e2e3685c149346d53a11f4137.camel@joachim-breitner.de> Dear committee, Vladislav proposed that we lower precedence for {-# UNPACK #-}: https://github.com/int-index/ghc-proposals/blob/unpack-pragma-precedence/proposals/0000-unpack-pragma-precedence.rst I’ll shepherd that myself. Simon already nodded, it’s half implemented and a clear win. Happy to recommend acceptance. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From eric at seidel.io Tue Oct 9 20:45:01 2018 From: eric at seidel.io (Eric Seidel) Date: Tue, 09 Oct 2018 16:45:01 -0400 Subject: [ghc-steering-committee] Proposal #173: The dot type operator, rec: accept Message-ID: <1539117901.1463756.1536405488.60C9EB2C@webmail.messagingengine.com> Hello, This proposal would extend the parser to allow the '.' character to appear in type operators, allowing one to write code like the following: ``` type (f . g) x = f (g x) foo :: (Maybe . Either Int) Bool foo = Just (Right True) ``` I recommend we accept the proposal, as it would resolve an odd inconsistency between the term and type languages. The main downside seems to be that combining a type-level '.' with a 'forall' is a bit hard to read, but I think the benefits of a more consistent syntax outweigh this concern. Eric From simonpj at microsoft.com Tue Oct 9 20:49:56 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 9 Oct 2018 20:49:56 +0000 Subject: [ghc-steering-committee] Proposal #173: The dot type operator, rec: accept In-Reply-To: <1539117901.1463756.1536405488.60C9EB2C@webmail.messagingengine.com> References: <1539117901.1463756.1536405488.60C9EB2C@webmail.messagingengine.com> Message-ID: I'm ok with this in principle, and I can't seen any bad disadvantages in practice. Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Eric Seidel | Sent: 09 October 2018 21:45 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Proposal #173: The dot type operator, | rec: accept | | Hello, | | This proposal would extend the parser to allow the '.' character to | appear in type operators, allowing one to write code like the following: | | ``` | type (f . g) x = f (g x) | | foo :: (Maybe . Either Int) Bool | foo = Just (Right True) | ``` | | I recommend we accept the proposal, as it would resolve an odd | inconsistency between the term and type languages. The main downside | seems to be that combining a type-level '.' with a 'forall' is a bit hard | to read, but I think the benefits of a more consistent syntax outweigh | this concern. | | Eric | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From rae at cs.brynmawr.edu Wed Oct 10 02:52:43 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 9 Oct 2018 22:52:43 -0400 Subject: [ghc-steering-committee] Proposal #173: The dot type operator, rec: accept In-Reply-To: <1539117901.1463756.1536405488.60C9EB2C@webmail.messagingengine.com> References: <1539117901.1463756.1536405488.60C9EB2C@webmail.messagingengine.com> Message-ID: I'm in support as well. Richard > On Oct 9, 2018, at 4:45 PM, Eric Seidel wrote: > > Hello, > > This proposal would extend the parser to allow the '.' character to appear in type operators, allowing one to write code like the following: > > ``` > type (f . g) x = f (g x) > > foo :: (Maybe . Either Int) Bool > foo = Just (Right True) > ``` > > I recommend we accept the proposal, as it would resolve an odd inconsistency between the term and type languages. The main downside seems to be that combining a type-level '.' with a 'forall' is a bit hard to read, but I think the benefits of a more consistent syntax outweigh this concern. > > Eric > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Thu Oct 11 14:47:28 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 11 Oct 2018 15:47:28 +0100 Subject: [ghc-steering-committee] Please review #166: List instances for a type in GHCi, Shepherd: Iavor Message-ID: <639ca7546118adc413dd076f3a59768723982a37.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: List instances for a type in GHCi, by Xavier Denis, was proposed https://github.com/ghc-proposals/ghc-proposals/pull/166 I propose Iavor 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 at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rae at cs.brynmawr.edu Thu Oct 11 21:45:36 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 11 Oct 2018 17:45:36 -0400 Subject: [ghc-steering-committee] Linear types (#111): conditional acceptance Message-ID: <9C200B92-B8E2-45F0-A423-52CD6B4CF423@cs.brynmawr.edu> Hi all, Several members of the steering committee met at ICFP to discuss the Linear Types proposal, #111. While some concerns were raised about the utility of the proposed approach (as also explained on the GitHub trail), the committee agreed that the best way forward would be to accept the proposal. I thus propose *conditional acceptance*, subject to these conditions, which were discussed at ICFP: 1. Error messages must remain free of mention of linear types, unless -XLinearTypes is in effect (or some flag like -fprint-linear-types is on). The same must be true of using the `:type` facility in GHCi. 2. Type inference must remain backward-compatible. All programs accepted today must be accepted when -XLinearTypes is not in effect. Ideally, these programs would also be accepted when -XLinearTypes is in effect, but there can be some wiggle room here. 3. Compile times for programs without -XLinearTypes must not unduly increase. Anything approaching or over a 2% across-the-board increase in compile times would be a cause for concern. 4. There must be no degradation in runtime performance of GHC-compiled programs. Linear types in Core might, for example, make some optimizations harder to apply; however, we must find a way to get runtime performance on par with what we have today. 5. There must be a story for a migration of `base`. The committee is concerned that, once linear types hits, there will be a great demand to incorporate linear types into `base`. (Note that `fmap` may want a linear type, and due to Functor's status as a superclass of Monad, `fmap` is really baked in.) How will this work? In particular, how will Haddock render newly-linearized types? 6. The theory of the linear types must be sound. This seems to be the case today, but as things evolve, we want to state explicitly that this must remain true. In particular, we must be able to rely on the safety of using linear mutable arrays. 7. There must be a specification (in some typeset document) of the new core language, written out for public inspection. If the final version of this should violate these prescriptions, it does not immediately mean we are at an impasse -- it just means that we need to have more discussion. Before officially posting this on #111 on behalf of the committee, I'd like some feedback on this recommendation. As usual, I'll take silence for agreement. Discussion period: 1 week (shortened due to the fact that many have already participated in formulating this list) Thanks! Richard From simonpj at microsoft.com Fri Oct 12 08:10:17 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 12 Oct 2018 08:10:17 +0000 Subject: [ghc-steering-committee] Linear types (#111): conditional acceptance In-Reply-To: <9C200B92-B8E2-45F0-A423-52CD6B4CF423@cs.brynmawr.edu> References: <9C200B92-B8E2-45F0-A423-52CD6B4CF423@cs.brynmawr.edu> Message-ID: I agree. I think that items 1-4 could be more clearly stated under the principle "pay as you go". That is: If a module does not use -XLinearTypes, it should not pay for it: - If a program typechecks now, it should continue to typecheck - Error messages should not become more confusing - :type should not become confusing - Compilation time should not increase significantly - Runtime should not increase (at all) But for all of these points there is wiggle room if -XLinearTypes is switched on. - We'd prefer that all existing type-correct programs remain so, but some corner cases might change - Error messages may well have to report linear stuff - Ditto :type - Compilation time should not increase markedly, but again there is more wiggle room - Runtime really should not increase. I don't want linearity to impede optimisation. For the migration-of-base question, I'm not sure it's reasonable to ask for a migration plan in advance. It's a tricky topic, as we saw with the Foldable and Monad/Applicative saga. Maybe we can say if/when pressure emerges to really make the linear functions part of base, we'd like to see a propose migration plan before execution? The CLC might play a role here too. Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Richard Eisenberg | Sent: 11 October 2018 22:46 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Linear types (#111): conditional | acceptance | | Hi all, | | Several members of the steering committee met at ICFP to discuss the | Linear Types proposal, #111. While some concerns were raised about the | utility of the proposed approach (as also explained on the GitHub trail), | the committee agreed that the best way forward would be to accept the | proposal. | | I thus propose *conditional acceptance*, subject to these conditions, | which were discussed at ICFP: | | 1. Error messages must remain free of mention of linear types, unless - | XLinearTypes is in effect (or some flag like -fprint-linear-types is on). | The same must be true of using the `:type` facility in GHCi. | | 2. Type inference must remain backward-compatible. All programs accepted | today must be accepted when -XLinearTypes is not in effect. Ideally, | these programs would also be accepted when -XLinearTypes is in effect, | but there can be some wiggle room here. | | 3. Compile times for programs without -XLinearTypes must not unduly | increase. Anything approaching or over a 2% across-the-board increase in | compile times would be a cause for concern. | | 4. There must be no degradation in runtime performance of GHC-compiled | programs. Linear types in Core might, for example, make some | optimizations harder to apply; however, we must find a way to get runtime | performance on par with what we have today. | | 5. There must be a story for a migration of `base`. The committee is | concerned that, once linear types hits, there will be a great demand to | incorporate linear types into `base`. (Note that `fmap` may want a linear | type, and due to Functor's status as a superclass of Monad, `fmap` is | really baked in.) How will this work? In particular, how will Haddock | render newly-linearized types? | | 6. The theory of the linear types must be sound. This seems to be the | case today, but as things evolve, we want to state explicitly that this | must remain true. In particular, we must be able to rely on the safety of | using linear mutable arrays. | | 7. There must be a specification (in some typeset document) of the new | core language, written out for public inspection. | | If the final version of this should violate these prescriptions, it does | not immediately mean we are at an impasse -- it just means that we need | to have more discussion. | | Before officially posting this on #111 on behalf of the committee, I'd | like some feedback on this recommendation. As usual, I'll take silence | for agreement. | | Discussion period: 1 week (shortened due to the fact that many have | already participated in formulating this list) | | Thanks! | Richard | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C303607a28a294ae7cd | f008d62fc2ea8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367489115454 | 76671&sdata=4ExqdXNPwu7CLr%2BV3FgfU8VDVbZsbW1DuMYdd5lNBh4%3D&rese | rved=0 From iavor.diatchki at gmail.com Fri Oct 12 16:36:23 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 12 Oct 2018 09:36:23 -0700 Subject: [ghc-steering-committee] Proposal #173: The dot type operator, rec: accept In-Reply-To: References: <1539117901.1463756.1536405488.60C9EB2C@webmail.messagingengine.com> Message-ID: Seems reasonable to me too. On Tue, Oct 9, 2018 at 7:52 PM Richard Eisenberg wrote: > I'm in support as well. > > Richard > > > On Oct 9, 2018, at 4:45 PM, Eric Seidel wrote: > > > > Hello, > > > > This proposal would extend the parser to allow the '.' character to > appear in type operators, allowing one to write code like the following: > > > > ``` > > type (f . g) x = f (g x) > > > > foo :: (Maybe . Either Int) Bool > > foo = Just (Right True) > > ``` > > > > I recommend we accept the proposal, as it would resolve an odd > inconsistency between the term and type languages. The main downside seems > to be that combining a type-level '.' with a 'forall' is a bit hard to > read, but I think the benefits of a more consistent syntax outweigh this > concern. > > > > Eric > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Mon Oct 15 16:11:57 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 15 Oct 2018 12:11:57 -0400 Subject: [ghc-steering-committee] Linear types (#111): conditional acceptance In-Reply-To: <9C200B92-B8E2-45F0-A423-52CD6B4CF423@cs.brynmawr.edu> References: <9C200B92-B8E2-45F0-A423-52CD6B4CF423@cs.brynmawr.edu> Message-ID: Revised proposal, in light of Simon's comments: I propose that #111 be *conditionally accepted*, with the following conditions. 1. The extension is pay-as-you-go; users who do not enable -XLinearTypes and who do not import modules that do should never need to know about the feature: a. Error messages must remain free of mention of linear types, unless -XLinearTypes is in effect (or some flag like -fprint-linear-types is on). The same must be true of using the `:type` facility in GHCi. b. Type inference must remain backward-compatible. All programs accepted today must be accepted when -XLinearTypes is not in effect. c. Compile times for programs without -XLinearTypes must not unduly increase. Anything approaching or over a 2% across-the-board increase in compile times would be a cause for concern. d. There must be no degradation in runtime performance of GHC-compiled programs. Linear types in Core might, for example, make some optimizations harder to apply; however, we must find a way to get runtime performance on par with what we have today. 2. We must work out an acceptable syntax for this all. In particular, : in types is taken by the list-cons operator, so we'll need something new. 3. The theory of the linear types must be sound. This seems to be the case today, but as things evolve, we want to state explicitly that this must remain true. In particular, we must be able to rely on the safety of using linear mutable arrays. 4. There must be a specification (in some typeset document) of the new core language, written out for public inspection. In addition to the stronger conditions above, we ask for these weaker conditions: 5. The worries in (1), above, should not become unduly worse when -XLinearTypes is enabled. For example, it is ideal if all programs that are accepted without -XLinearTypes are still accepted with -XLinearTypes, but there is considerably more wiggle room here. Similarly with compile times: a compile-time regression with -XLinearTypes are more acceptable than a regression without -XLinearTypes, but would still be a cause for concern. 6. There should be a story for a migration of `base`. The committee is concerned that, once linear types hits, there will be a great demand to incorporate linear types into `base`. (Note that `fmap` may want a linear type, and due to Functor's status as a superclass of Monad, `fmap` is really baked in.) How will this work? In particular, how will Haddock render newly-linearized types? If the final version of -XLinearTypes should violate these prescriptions, it does not immediately mean we are at an impasse -- it just means that we need to have more discussion. More comments / suggestions are very welcome! Richard From mail at joachim-breitner.de Mon Oct 15 22:08:59 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 16 Oct 2018 00:08:59 +0200 Subject: [ghc-steering-committee] Please review #175: Lift.liftTyped, Shepherd: Ben Gamari Message-ID: Dear Committee, this is your secretary speaking: Add `liftTyped` to the `Lift` typeclass, by Alec Theriault, was proposed https://github.com/ghc-proposals/ghc-proposals/pull/175 https://github.com/harpocrates/ghc-proposals/blob/lift-typed/proposals/0000-lift-typed.rst I propose Ben 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 at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Oct 16 16:02:40 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 16 Oct 2018 16:02:40 +0000 Subject: [ghc-steering-committee] Linear types (#111): conditional acceptance In-Reply-To: References: <9C200B92-B8E2-45F0-A423-52CD6B4CF423@cs.brynmawr.edu> Message-ID: LGTM -- thanks | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Richard Eisenberg | Sent: 15 October 2018 17:12 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Linear types (#111): conditional | acceptance | | Revised proposal, in light of Simon's comments: | | I propose that #111 be *conditionally accepted*, with the following | conditions. | | 1. The extension is pay-as-you-go; users who do not enable -XLinearTypes | and who do not import modules that do should never need to know about the | feature: | a. Error messages must remain free of mention of linear types, unless - | XLinearTypes is in effect (or some flag like -fprint-linear-types is on). | The same must be true of using the `:type` facility in GHCi. | b. Type inference must remain backward-compatible. All programs | accepted today must be accepted when -XLinearTypes is not in effect. | c. Compile times for programs without -XLinearTypes must not unduly | increase. Anything approaching or over a 2% across-the-board increase in | compile times would be a cause for concern. | d. There must be no degradation in runtime performance of GHC-compiled | programs. Linear types in Core might, for example, make some | optimizations harder to apply; however, we must find a way to get runtime | performance on par with what we have today. | | 2. We must work out an acceptable syntax for this all. In particular, : | in types is taken by the list-cons operator, so we'll need something new. | | 3. The theory of the linear types must be sound. This seems to be the | case today, but as things evolve, we want to state explicitly that this | must remain true. In particular, we must be able to rely on the safety of | using linear mutable arrays. | | 4. There must be a specification (in some typeset document) of the new | core language, written out for public inspection. | | In addition to the stronger conditions above, we ask for these weaker | conditions: | | 5. The worries in (1), above, should not become unduly worse when - | XLinearTypes is enabled. For example, it is ideal if all programs that | are accepted without -XLinearTypes are still accepted with -XLinearTypes, | but there is considerably more wiggle room here. Similarly with compile | times: a compile-time regression with -XLinearTypes are more acceptable | than a regression without -XLinearTypes, but would still be a cause for | concern. | | 6. There should be a story for a migration of `base`. The committee is | concerned that, once linear types hits, there will be a great demand to | incorporate linear types into `base`. (Note that `fmap` may want a linear | type, and due to Functor's status as a superclass of Monad, `fmap` is | really baked in.) How will this work? In particular, how will Haddock | render newly-linearized types? | | If the final version of -XLinearTypes should violate these prescriptions, | it does not immediately mean we are at an impasse -- it just means that | we need to have more discussion. | | More comments / suggestions are very welcome! | Richard | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50550b93f6a448a406 | 7608d632b8f7d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367521673523 | 59760&sdata=eVCZLRwjfzjHYjd5bdF%2BRw5kj%2B92jskU9eJOjwzExig%3D&re | served=0 From rae at cs.brynmawr.edu Wed Oct 17 14:54:53 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 17 Oct 2018 10:54:53 -0400 Subject: [ghc-steering-committee] Please Review: Show Types as Symbols (#164), Shepherd: Richard Eisenberg In-Reply-To: References: <076c8de4d3619c45139494cdb61f7c9fb50c579a.camel@joachim-breitner.de> Message-ID: <8EB392CA-ED26-481F-9455-FEA6EACC3B2D@cs.brynmawr.edu> Hi Sandy, This one looks like it's in your court. I see that you commented on Sep 27 that you would try to update, so I moved this out of my queue. If you'd like to submit to the committee (without those updates), post on the GitHub trail and I'll swing into action. Thanks, Richard > On Sep 21, 2018, at 10:56 AM, Sandy Maguire wrote: > > Gentle ping on this! > > On Fri, Sep 7, 2018 at 3:54 PM, Joachim Breitner > wrote: >> Dear Committee, >> >> this is your secretary speaking: >> >> Provide a primitive to show types as Symbols, by Sandy Maguirer, was proposed >> https://github.com/ghc-proposals/ghc-proposals/pull/164 >> >> I propose Richard as the shepherd, he already showed interest in this proposal. >> >> 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 at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From bravit111 at gmail.com Fri Oct 19 00:56:50 2018 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Thu, 18 Oct 2018 17:56:50 -0700 Subject: [ghc-steering-committee] Linear types (#111): conditional acceptance In-Reply-To: References: <9C200B92-B8E2-45F0-A423-52CD6B4CF423@cs.brynmawr.edu> Message-ID: With item 4 in mind: shouldn't we require explicitly this new specification to be an extension or revision of your current 'System FC, as implemented in GHC' paper in docs/core-spec/core-spec.pdf with the same structure etc. That'd give this document more formal status which is convenient for referring to it later. Vitaly On Mon, Oct 15, 2018 at 9:12 AM Richard Eisenberg wrote: > Revised proposal, in light of Simon's comments: > > I propose that #111 be *conditionally accepted*, with the following > conditions. > > 1. The extension is pay-as-you-go; users who do not enable -XLinearTypes > and who do not import modules that do should never need to know about the > feature: > a. Error messages must remain free of mention of linear types, unless > -XLinearTypes is in effect (or some flag like -fprint-linear-types is on). > The same must be true of using the `:type` facility in GHCi. > b. Type inference must remain backward-compatible. All programs accepted > today must be accepted when -XLinearTypes is not in effect. > c. Compile times for programs without -XLinearTypes must not unduly > increase. Anything approaching or over a 2% across-the-board increase in > compile times would be a cause for concern. > d. There must be no degradation in runtime performance of GHC-compiled > programs. Linear types in Core might, for example, make some optimizations > harder to apply; however, we must find a way to get runtime performance on > par with what we have today. > > 2. We must work out an acceptable syntax for this all. In particular, : in > types is taken by the list-cons operator, so we'll need something new. > > 3. The theory of the linear types must be sound. This seems to be the case > today, but as things evolve, we want to state explicitly that this must > remain true. In particular, we must be able to rely on the safety of using > linear mutable arrays. > > 4. There must be a specification (in some typeset document) of the new > core language, written out for public inspection. > > In addition to the stronger conditions above, we ask for these weaker > conditions: > > 5. The worries in (1), above, should not become unduly worse when > -XLinearTypes is enabled. For example, it is ideal if all programs that are > accepted without -XLinearTypes are still accepted with -XLinearTypes, but > there is considerably more wiggle room here. Similarly with compile times: > a compile-time regression with -XLinearTypes are more acceptable than a > regression without -XLinearTypes, but would still be a cause for concern. > > 6. There should be a story for a migration of `base`. The committee is > concerned that, once linear types hits, there will be a great demand to > incorporate linear types into `base`. (Note that `fmap` may want a linear > type, and due to Functor's status as a superclass of Monad, `fmap` is > really baked in.) How will this work? In particular, how will Haddock > render newly-linearized types? > > If the final version of -XLinearTypes should violate these prescriptions, > it does not immediately mean we are at an impasse -- it just means that we > need to have more discussion. > > More comments / suggestions are very welcome! > Richard > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bravit111 at gmail.com Sat Oct 20 16:39:54 2018 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Sat, 20 Oct 2018 09:39:54 -0700 Subject: [ghc-steering-committee] Proposal #170: Unrestricted OverloadedLabels (was: Uppercase OverloadedLabels), rec: accept Message-ID: Hi all, The proposal #170: Unrestricted OverloadedLabels (was: Uppercase OverloadedLabels) (https://github.com/ghc-proposals/ghc-proposals/pull/170) was updated to allow any nonempty alphanumeric string following a # under OverloadedLabels. So I repeat my recommendation to accept it. Please speak up within a week if you have any concerns. Silence is understood as agreement. Regards, Vitaly -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sat Oct 20 17:19:52 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 20 Oct 2018 19:19:52 +0200 Subject: [ghc-steering-committee] Proposal #174: Lower precedence for {-# UNPACK #-}, rec: accept In-Reply-To: <268c3f6df5cd071e2e3685c149346d53a11f4137.camel@joachim-breitner.de> References: <268c3f6df5cd071e2e3685c149346d53a11f4137.camel@joachim-breitner.de> Message-ID: <6e66d51b2ff1f2f07ff8c499ebd81b54ed908671.camel@joachim-breitner.de> Hi, Am Dienstag, den 09.10.2018, 18:44 +0100 schrieb Joachim Breitner: > Vladislav proposed that we lower precedence for {-# UNPACK #-}: > https://github.com/int-index/ghc-proposals/blob/unpack-pragma-precedence/proposals/0000-unpack-pragma-precedence.rst > > I’ll shepherd that myself. > > Simon already nodded, it’s half implemented and a clear win. Happy > to recommend acceptance. I consider this accepted. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Sun Oct 21 09:37:54 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 21 Oct 2018 11:37:54 +0200 Subject: [ghc-steering-committee] Proposal #168: fail with OverloadedStrings, rec: accept In-Reply-To: References: Message-ID: <6d982bc793dd181b6670f58844ec078f758ec7cc.camel@joachim-breitner.de> Hi, Am Sonntag, den 30.09.2018, 10:38 -0700 schrieb Joachim Breitner: > Dear committee, > > welcome back from ICFP! Those who missed it: it was great, watch the > videos, come to Berlin next year. > > Shayne Fletcher proposed that in the presence of both RebindableSyntax > and OverloadedStrings, the implicit calls to fail produces by the > compiler should wrap the arguments in `fromString`: > https://github.com/shayne-fletcher-da/ghc-proposals/blob/fail-rebindable-with-overloaded-strings/proposals/0000-fail-rebindable-with-overloaded-strings.rst > > I’ll shepherd that myself. > > I agree with Neil Mitchell in the assessment that this feels more like > a bug fix than a proposal, and support acceptance. already three weeks since ICFP? Well, this is now also accepted. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From iavor.diatchki at gmail.com Fri Oct 26 17:59:30 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 26 Oct 2018 10:59:30 -0700 Subject: [ghc-steering-committee] Discussion: List instances for a type in GHCi #166 Message-ID: Hello, I'd like to start the discussion about feature request #166, "List instances for a type in GHCi". In short, the idea is that we add a new command to GHCi, `:instances TYPE`, which given a type, will show the list of instances---for any class---that could be used with this type. It seems like this could be a potentially handy thing to do, and it doesn't really interfere with anything else, so I recommend that we accept it. Please let me know what you think. -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Mon Oct 29 04:16:29 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 29 Oct 2018 00:16:29 -0400 Subject: [ghc-steering-committee] Discussion: List instances for a type in GHCi #166 In-Reply-To: References: Message-ID: <21E0BBB5-FE62-4620-983D-A928A230A70A@cs.brynmawr.edu> Yes, I'm in favor. Richard > On Oct 26, 2018, at 1:59 PM, Iavor Diatchki wrote: > > Hello, > > I'd like to start the discussion about feature request #166, "List instances for a type in GHCi". In short, the idea is that we add a new command to GHCi, `:instances TYPE`, which given a type, will show the list of instances---for any class---that could be used with this type. > > It seems like this could be a potentially handy thing to do, and it doesn't really interfere with anything else, so I recommend that we accept it. > > Please let me know what you think. > > -Iavor > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee