From simonpj at microsoft.com Mon Dec 3 16:08:54 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 3 Dec 2018 16:08:54 +0000 Subject: [ghc-steering-committee] GHC proposals Message-ID: Joachim * Could we add a tag for "Implemented" so that we can have convenient lists for "accepted and implemented" vs "accepted and not yet implemented"? Easy, and valuable. * The "under discussion" list seems terribly short - only two proposals! https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no%3Alabel There are tons of proposals under discussion! What's wrong? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Dec 3 16:19:08 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 03 Dec 2018 17:19:08 +0100 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: Hi, Am Montag, den 03.12.2018, 16:08 +0000 schrieb Simon Peyton Jones: > Joachim > Could we add a tag for “Implemented” so that we can have convenient lists for “accepted and implemented” vs “accepted and not yet implemented”? Easy, and valuable. So far I shied away from the bureaucracy of having to track what happens after acceptance (including keeping the `trac` and `implemented` fields on top up-to-date). Occasionally people have updated this metadata. I am happy to introduce an Implemented label, but do not promise that I will track GHC changes close enough to always set it correctly. Do we consider it as implemented when a DR is created, when it hits master, or when it is released? > The “under discussion” list seems terribly short – only two proposals! > https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no%3Alabel > There are tons of proposals under discussion! What’s wrong? Oh, darn! Vitaly started tagging Proposals with the tag “Proposal”, which is a nice idea, but it breaks the current setup where “no tag” means “Proposal under discussion”. Not using a tag was a deliberate choice, as it has the advantage that newly created proposals are automatically correctly categorized. Note that contributors who are not members of the team don’t have permissions to set a tag, so we can’t ask them to set a “Under discussion“ tag. Vitaly, how about we delete the Proposal tag, and maybe mark non- proposals with a tag (maybe with a grey or dull color). Given that most pull requests are proposals, let’s mark the exceptions instead! 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 bravit111 at gmail.com Mon Dec 3 16:24:39 2018 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Mon, 3 Dec 2018 11:24:39 -0500 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: Vitaly, how about we delete the Proposal tag, and maybe mark non- > proposals with a tag (maybe with a grey or dull color). Given that most > pull requests are proposals, let’s mark the exceptions instead! > > Ok, I'll do that. Sorry for messing things up, I wanted to count all proposals but took a longer road. Vitaly -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Dec 3 16:39:52 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 03 Dec 2018 17:39:52 +0100 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: <03492236279d3b634ed9f7964e13ce0238002386.camel@joachim-breitner.de> Hi, Am Montag, den 03.12.2018, 11:24 -0500 schrieb Vitaly Bragilevsky: > Vitaly, how about we delete the Proposal tag, and maybe mark non- > > proposals with a tag (maybe with a grey or dull color). Given that most > > pull requests are proposals, let’s mark the exceptions instead! > > > > Ok, I'll do that. Sorry for messing things up, I wanted to count all proposals but took a longer road. depending on what you want to do, the code at https://github.com/nomeata/ghc-proposals-stats might be useful. 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 bravit111 at gmail.com Mon Dec 3 16:41:16 2018 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Mon, 3 Dec 2018 11:41:16 -0500 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: Hi, I've fixed "under discussion" list and added "Non-proposal" label. I am volunteering to keep track of the implemented proposals with "Implemented" label. I think hitting master is the right time to consider the proposal implemented, are there other ideas on that? Vitaly On Mon, Dec 3, 2018 at 8:24 AM Vitaly Bragilevsky wrote: > Vitaly, how about we delete the Proposal tag, and maybe mark non- >> proposals with a tag (maybe with a grey or dull color). Given that most >> pull requests are proposals, let’s mark the exceptions instead! >> >> > Ok, I'll do that. Sorry for messing things up, I wanted to count all > proposals but took a longer road. > > Vitaly > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Dec 3 16:45:21 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 03 Dec 2018 17:45:21 +0100 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: <2f35e25d0a157ec1a0de07c8379466e30abac366.camel@joachim-breitner.de> Hi, Am Montag, den 03.12.2018, 11:41 -0500 schrieb Vitaly Bragilevsky: > I've fixed "under discussion" list and added "Non-proposal" label. Great! > I am volunteering to keep track of the implemented proposals with > "Implemented" label. I think hitting master is the right time to > consider the proposal implemented, are there other ideas on that? Even greater. Agreed that hitting master is the right time. 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 simonpj at microsoft.com Mon Dec 3 17:09:29 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 3 Dec 2018 17:09:29 +0000 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: * I agree with “hitting master”. * The “implemented status does not need to be 100% up to date; but it would be good to explain how to ask for a proposal to be moved from “accepted” to “implemented”. * There should be a link in the “timeline” list on https://github.com/ghc-proposals/ghc-proposals, so that people can find the list. Perhaps “6. Later, someone may implement the proposal. We count it as “implemented” when it hits the GHC mater banch” THanks! Simon From: Vitaly Bragilevsky Sent: 03 December 2018 16:41 To: Joachim Breitner Cc: Simon Peyton Jones ; ghc-steering-committee Subject: Re: GHC proposals Hi, I've fixed "under discussion" list and added "Non-proposal" label. I am volunteering to keep track of the implemented proposals with "Implemented" label. I think hitting master is the right time to consider the proposal implemented, are there other ideas on that? Vitaly On Mon, Dec 3, 2018 at 8:24 AM Vitaly Bragilevsky > wrote: Vitaly, how about we delete the Proposal tag, and maybe mark non- proposals with a tag (maybe with a grey or dull color). Given that most pull requests are proposals, let’s mark the exceptions instead! Ok, I'll do that. Sorry for messing things up, I wanted to count all proposals but took a longer road. Vitaly -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Dec 3 17:19:43 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 03 Dec 2018 18:19:43 +0100 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: <188626312ad12a48f9e5c90252480c42f6ed3d50.camel@joachim-breitner.de> Hi, Am Montag, den 03.12.2018, 17:09 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > The “implemented status does not need to be 100% up to date; but it would be good to explain how to ask for a proposal to be moved from “accepted” to “implemented”. Yup > There should be a link in the “timeline” list on > https://github.com/ghc-proposals/ghc-proposals, so that people can > find the list. Perhaps “6. Later, someone may implement the > proposal. We count it as “implemented” when it hits the GHC mater > banch” Good point, added: https://github.com/ghc-proposals/ghc-proposals#what-is-the-timeline-of-a-proposal 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 simonpj at microsoft.com Tue Dec 4 16:21:54 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 4 Dec 2018 16:21:54 +0000 Subject: [ghc-steering-committee] Guidelines for respectful communication Message-ID: Friends on the GHC steering group Joachim has published our new guidelines, here https://github.com/ghc-proposals/ghc-proposals/blob/master/GRC.rst I'll send an email to ... what... ghc-users and ghc-devs perhaps. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Dec 6 10:35:11 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 6 Dec 2018 10:35:11 +0000 Subject: [ghc-steering-committee] Guidelines for respectful communication Message-ID: Friends As many of you will know, I have been concerned for several years about the standards of discourse in the Haskell community. I think things have improved since the period that drove me to write my Respect email, but it's far from secure. We discussed this at a meeting of the GHC Steering Committee at ICFP in September, and many of us have had related discussions since. Arising out of that conversation, the GHC Steering Committee has decided to adopt these Guidelines for respectful communication We are not trying to impose these guidelines on members of the Haskell community generally. Rather, we are adopting them for ourselves, as a signal that we seek high standards of discourse in the Haskell community, and are willing to publicly hold ourselves to that standard, in the hope that others may choose to follow suit. We are calling them "guidelines for respectful communication" rather than a "code of conduct", because we want to encourage good communication, rather than focus on bad behaviour. Richard Stallman's recent post about the new GNU Kind Communication Guidelines expresses the same idea. Meanwhile, the Stack community is taking a similar approach. Our guidelines are not set in stone; you can comment here. Perhaps they can evolve so that other Haskell committees (or even individuals) feel able to adopt them. The Haskell community is such a rich collection of intelligent, passionate, and committed people. Thank you -- I love you all! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Dec 16 21:37:58 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 16 Dec 2018 22:37:58 +0100 Subject: [ghc-steering-committee] Please review #158: HasField-setField, Shepherd: Iavor Message-ID: Dear Committee, this is your secretary speaking: Adding `setField` to `HasField` has been proposed by Neil Mitchell: https://github.com/ghc-proposals/ghc-proposals/pull/158 https://github.com/ndmitchell/ghc-proposals/blob/patch-1/proposals/0000-record-set-field.rst 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 mail at joachim-breitner.de Sun Dec 16 21:42:05 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 16 Dec 2018 22:42:05 +0100 Subject: [ghc-steering-committee] Status Message-ID: <5d9ca51e35e3c92e36f04c2e4c4998b45f6c1936.camel@joachim-breitner.de> Dear committee, ’tis the season – but not for committee work, it seems. Well, here is what happened: * were asked to review these proposals: #158 The HasField-setfield proposal (shepherd: Iavor) * got a recommendation from shepherds about: #175 Lift.liftTyped (rec: accept) * decided about the following proposals -none- We currently have to act on the following 7 proposals, one up from last time. Most saw no activity in the last month! liftTyped https://github.com/ghc-proposals/ghc-proposals/pull/175 Shepherd: Ben Status: Acceptance recommended, but a discussion ensured and did not conclude. Ben, Eric, what is the status. record-set-field proposal https://github.com/ghc-proposals/ghc-proposals/pull/158 Shepherd: Yav Status: Waiting for a recommendation. Type annotated quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Shepherd: Manuel Status: Still waiting for recommendation. Manuel? Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Status: Still waiting for recommendation. This is pretty old! ExtraCommas https://github.com/ghc-proposals/ghc-proposals/pull/87 Shepherd: Chris Recommendation: accept Status: Met with some reservation. Chris, please pick this up again. Or-Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Recommendation: accept Status: Round 2 discussion ebbed down. Manuel, can you conclude this? Bundling patterns with synonyms https://github.com/ghc-proposals/ghc-proposals/pull/28 Shepherd: Chris Recommendation: reject Status: Chris, you still need to write the rejection reasons to the ticket. 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 watson.timothy at gmail.com Sat Dec 8 18:08:22 2018 From: watson.timothy at gmail.com (Tim Watson) Date: Sat, 8 Dec 2018 18:08:22 +0000 Subject: [ghc-steering-committee] Guidelines for respectful communication In-Reply-To: References: Message-ID: I think this is brilliant. Will have a good read of them, and do my best to adopt them for my own projects and any interactions I have within the community. Thank you Simon! PS: we love you too! :D On Thu, 6 Dec 2018 at 10:35, Simon Peyton Jones via Glasgow-haskell-users < glasgow-haskell-users at haskell.org> wrote: > Friends > As many of you will know, I have been concerned for several years about > the standards of discourse in the Haskell community. I think things have > improved since the period that drove me to write my Respect email< > https://mail.haskell.org/pipermail/haskell/2016-September/024995.html>, > but it's far from secure. > We discussed this at a meeting of the GHC Steering Committee< > https://github.com/ghc-proposals/ghc-proposals> at ICFP in September, and > many of us have had related discussions since. Arising out of that > conversation, the GHC Steering Committee has decided to adopt these > Guidelines for respectful communication< > https://github.com/ghc-proposals/ghc-proposals/blob/master/GRC.rst> > > We are not trying to impose these guidelines on members of the Haskell > community generally. Rather, we are adopting them for ourselves, as a > signal that we seek high standards of discourse in the Haskell community, > and are willing to publicly hold ourselves to that standard, in the hope > that others may choose to follow suit. > We are calling them "guidelines for respectful communication" rather than > a "code of conduct", because we want to encourage good communication, > rather than focus on bad behaviour. Richard Stallman's recent post< > https://lwn.net/Articles/769167/> about the new GNU Kind Communication > Guidelines expresses > the same idea. > Meanwhile, the Stack community is taking a similar approach< > https://www.snoyman.com/blog/2018/11/proposal-stack-coc>. > Our guidelines are not set in stone; you can comment here< > https://github.com/ghc-proposals/ghc-proposals/commit/373044b5a78519071b9a24b3681cfd1af06e57e0>. > Perhaps they can evolve so that other Haskell committees (or even > individuals) feel able to adopt them. > The Haskell community is such a rich collection of intelligent, > passionate, and committed people. Thank you -- I love you all! > Simon > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Tue Dec 18 18:02:01 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 18 Dec 2018 10:02:01 -0800 Subject: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`" Message-ID: Hello, let's start the discussion on proposal #158. After some discussion on the pull request the proposal was changed, so that instead of adding another method, it now proposes to remove the existing method `getField`, and add a new method `hasField`, which allows to both access and change the value of a field. After the proposal the class would look like this -- `x` is the name of the field, `r` is the type of the record, `a` is the type of the field class HasField x r a | x r -> a where hasField :: r -> (a -> r, a) In addition, we'd provide two functions `getField` and `setField` which are defined in terms of `hasField`. The proposal may break existing code, if it defines manual instances of `HasField`, however, code that just uses the functionality will continue working as before. `HasField` is relatively new, and there aren't many reasons to define custom instances of it, so it is expected that breaking code would not be a big issue. This seems like a reasonably simple change, that adds new functionality, so I recommend that we accept the change. -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Wed Dec 19 03:37:08 2018 From: eric at seidel.io (Eric Seidel) Date: Tue, 18 Dec 2018 22:37:08 -0500 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <592230B0-33F9-468F-8676-F6DED97E49CE@seidel.io> References: <87zhunv09p.fsf@smart-cactus.org> <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> <592230B0-33F9-468F-8676-F6DED97E49CE@seidel.io> Message-ID: <1545190628.935552.1613138120.0DE606A9@webmail.messagingengine.com> To recap the discussion so far (thanks Joachim!): - Ben recommended accepance. - Richard pointed out that the proposed change will break instances that rely on the default method in a very bad way: they will compile but loop at runtime due to the mutually recursive defaults. - Iavor replied that it seems unlikely that much code would be affected, as DeriveLift has been the recommended strategy for a long time. I'm inclined to agree with Iavor that the actual impact is likely to be minimal, but this is something we could investigate with a scan of Hackage. (I believe people have done this in the past, so there may even be some scripts we can repurpose?) We could also mitigate the issue in a couple ways: 1. We could make violations of MINIMAL pragmas errors instead of warnings. This would need its own proposal, but it seems like a good idea to me regardless. 2. We could add a special warning/error for empty Lift instances. This is ad-hoc and kludgy, but easily doable since template-haskell is bundled with ghc. 3. We could provide a ghc-fix tool that automatically fixes this issue (and maybe others!). A number of other languages do this and it seems to work well for them. It also sounds like a very nice application of the ghc-exactprint work that Alan has done. On Wed, Nov 7, 2018, at 12:45, Eric Seidel wrote: > This is a wonderfully clever idea, but it has the unfortunate > consequence of making the new default lift (written in terms of > liftTyped) unusable even if you provide a custom liftTyped. I’ve had to > write my own lift on occasion (eg for types that contain Text fields), > so this is something we should consider. That being said, the > consequence of the TypeError fix is that custom instances will need an > extra one-line definition of lift, which is not that severe. > > This whole issue does make me wonder though, why does a violation of the > MINIMAL pragma produce a warning rather than an error? It seems like the > standard use case is to describe how one can break a chain of mutually- > recursive default definitions. Failure to do so will result in a non- > terminating program, which really ought to be an error. > > Sent from my iPhone > > > On Nov 7, 2018, at 10:40, Richard Eisenberg wrote: > > > > If we really want to encourage users to use `DeriveLift`, we could do something like > > > > class Lift t where > > ... > > default lift :: TypeError "Use DeriveLift" => ... > > > > Then, anyone relying on the old behavior would get a beautiful error message telling them exactly how to migrate. > > > > Richard > > > >> On Nov 5, 2018, at 6:31 PM, Iavor Diatchki wrote: > >> > >> Hello, > >> > >> I'd be surprised if there is a lot of code affected by that. Either way, I guess this wouldn't be an issue, if we just changed the proposal to make the default instance for `typedLift` looks like the old default for `lift` (i.e., use the `Data` constraint). > >> > >> The proposed design does have two benefits though: > >> * The new design requires fewer GHC extensions (no need for `DefaultSignatures`) > >> * It encourages programmers to use `DeriveLift`, which is shorter, safer, and more direct. > >> > >> -Iavor > >> > >> > >> > >>> On Mon, Nov 5, 2018 at 10:50 AM Richard Eisenberg wrote: > >>> Will this break existing code? The proposal suggests that liftTyped will have a suitable default implementation. > >>> > >>> Actually, this will break code, but not in the way one might think (with an undefined liftTyped). Instead, the proposal removes the default implementation of lift to use liftTyped. This means that any code relying on the default implementation of lift will now have an instance with mutually recursive, non-terminating methods. And this will all be silent. And, it's something that might be discovered only in clients of a library, rather than in the library itself. So I think that's pretty problematic. Even with our recommendation to derive Lift instances, this change in behavior is so terrible that it makes me lean against the proposal. Is there a design / migration path that avoids this problem? > >>> > >>> (Yes, yes, I know that I could voiced this opinion earlier, but it didn't occur to me until just now.) > >>> > >>> Richard > >>> > >>> > On Nov 5, 2018, at 1:37 PM, Ben Gamari wrote: > >>> > > >>> > Hi everyone, > >>> > > >>> > I have been asked to Shepard #175, which proposes to add a `liftTyped` > >>> > method to the `Lift` typeclass used to lift Haskell values into Template > >>> > Haskell splices. Currently the `Lift` typeclass provides no guarantee of > >>> > type-safety, even when used in a Typed Template Haskell context. > >>> > > >>> > The proposal resolves this limitation by adding a typed lifting > >>> > operation to the `Lift` class: > >>> > > >>> > class Lift t where > >>> > lift :: t -> Q Exp > >>> > liftTyped :: t -> Q (TExp t) > >>> > > >>> > While this addition will break manually-written `Lift` instances, we > >>> > recommended that users derive such instances for quite a while now, so > >>> > it is not expected that the breakage will be wide-spread. In light of > >>> > this, I recommend that we accept this proposal. > >>> > > >>> > Given that we will likely want to get this in to 8.8, I suggest that we > >>> > limit the discussion to a week unless there is dissent. > >>> > > >>> > Cheers, > >>> > > >>> > - Ben > >>> > _______________________________________________ > >>> > 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 > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From simonpj at microsoft.com Wed Dec 19 09:04:26 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 19 Dec 2018 09:04:26 +0000 Subject: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`" In-Reply-To: References: Message-ID: Iavor I’m broadly happy, but I would like us (and the proposers) to discuss the question of using a type family instead of a fundep. See my comment at https://github.com/ghc-proposals/ghc-proposals/pull/158#issuecomment-448520004 Simon From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 18 December 2018 18:02 To: ghc-steering-committee Subject: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`" Hello, let's start the discussion on proposal #158. After some discussion on the pull request the proposal was changed, so that instead of adding another method, it now proposes to remove the existing method `getField`, and add a new method `hasField`, which allows to both access and change the value of a field. After the proposal the class would look like this -- `x` is the name of the field, `r` is the type of the record, `a` is the type of the field class HasField x r a | x r -> a where hasField :: r -> (a -> r, a) In addition, we'd provide two functions `getField` and `setField` which are defined in terms of `hasField`. The proposal may break existing code, if it defines manual instances of `HasField`, however, code that just uses the functionality will continue working as before. `HasField` is relatively new, and there aren't many reasons to define custom instances of it, so it is expected that breaking code would not be a big issue. This seems like a reasonably simple change, that adds new functionality, so I recommend that we accept the change. -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Dec 19 09:17:01 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 19 Dec 2018 10:17:01 +0100 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <1545190628.935552.1613138120.0DE606A9@webmail.messagingengine.com> References: <87zhunv09p.fsf@smart-cactus.org> <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> <592230B0-33F9-468F-8676-F6DED97E49CE@seidel.io> <1545190628.935552.1613138120.0DE606A9@webmail.messagingengine.com> Message-ID: Hi, thanks for the summary! Am Dienstag, den 18.12.2018, 22:37 -0500 schrieb Eric Seidel: > 1. We could make violations of MINIMAL pragmas errors instead of > warnings. This would need its own proposal, but it seems like a good > idea to me regardless. > > 2. We could add a special warning/error for empty Lift instances. > This is ad-hoc and kludgy, but easily doable since template-haskell > is bundled with ghc. > > 3. We could provide a ghc-fix tool that automatically fixes this > issue (and maybe others!). A number of other languages do this and it > seems to work well for them. It also sounds like a very nice > application of the ghc-exactprint work that Alan has done. I think 1. is at odds in GHC – we allow partiality in other places as well (partially initialized records, for example). Disallowing it feels like a too fundamental change to the language for the problem we need to solve here. 3. is a neat idea, but again a very big cannon for a niche problem. If we _had_ ghc-fix, then this might be a good approach, and we can keep this in mind as additional evidence that ghc-fix would be good (GSOC anyone), but let's not wait for that here. 2. is good, I think. We have had plenty of such kludges, e.g. around the Monad refactoring. 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 simonpj at microsoft.com Wed Dec 19 09:28:10 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 19 Dec 2018 09:28:10 +0000 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <1545190628.935552.1613138120.0DE606A9@webmail.messagingengine.com> References: <87zhunv09p.fsf@smart-cactus.org> <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> <592230B0-33F9-468F-8676-F6DED97E49CE@seidel.io> <1545190628.935552.1613138120.0DE606A9@webmail.messagingengine.com> Message-ID: Is there any reason for not adopting the second alternative in section 5: make liftTyped the sole method of Lift? I have elaborated on the tracker https://github.com/ghc-proposals/ghc-proposals/pull/175#issuecomment-448527596 Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Eric Seidel | Sent: 19 December 2018 03:37 | To: ghc-steering-committee | Subject: Re: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped | (recommendation: accept) | | To recap the discussion so far (thanks Joachim!): | | - Ben recommended accepance. | - Richard pointed out that the proposed change will break instances that | rely on the default method in a very bad way: they will compile but loop at | runtime due to the mutually recursive defaults. | - Iavor replied that it seems unlikely that much code would be affected, as | DeriveLift has been the recommended strategy for a long time. | | I'm inclined to agree with Iavor that the actual impact is likely to be | minimal, but this is something we could investigate with a scan of Hackage. | (I believe people have done this in the past, so there may even be some | scripts we can repurpose?) | | We could also mitigate the issue in a couple ways: | | 1. We could make violations of MINIMAL pragmas errors instead of warnings. | This would need its own proposal, but it seems like a good idea to me | regardless. | 2. We could add a special warning/error for empty Lift instances. This is | ad-hoc and kludgy, but easily doable since template-haskell is bundled with | ghc. | 3. We could provide a ghc-fix tool that automatically fixes this issue (and | maybe others!). A number of other languages do this and it seems to work | well for them. It also sounds like a very nice application of the ghc- | exactprint work that Alan has done. | | On Wed, Nov 7, 2018, at 12:45, Eric Seidel wrote: | > This is a wonderfully clever idea, but it has the unfortunate | > consequence of making the new default lift (written in terms of | > liftTyped) unusable even if you provide a custom liftTyped. I’ve had | > to write my own lift on occasion (eg for types that contain Text | > fields), so this is something we should consider. That being said, the | > consequence of the TypeError fix is that custom instances will need an | > extra one-line definition of lift, which is not that severe. | > | > This whole issue does make me wonder though, why does a violation of | > the MINIMAL pragma produce a warning rather than an error? It seems | > like the standard use case is to describe how one can break a chain of | > mutually- recursive default definitions. Failure to do so will result | > in a non- terminating program, which really ought to be an error. | > | > Sent from my iPhone | > | > > On Nov 7, 2018, at 10:40, Richard Eisenberg | wrote: | > > | > > If we really want to encourage users to use `DeriveLift`, we could | > > do something like | > > | > > class Lift t where | > > ... | > > default lift :: TypeError "Use DeriveLift" => ... | > > | > > Then, anyone relying on the old behavior would get a beautiful error | message telling them exactly how to migrate. | > > | > > Richard | > > | > >> On Nov 5, 2018, at 6:31 PM, Iavor Diatchki | wrote: | > >> | > >> Hello, | > >> | > >> I'd be surprised if there is a lot of code affected by that. Either | way, I guess this wouldn't be an issue, if we just changed the proposal to | make the default instance for `typedLift` looks like the old default for | `lift` (i.e., use the `Data` constraint). | > >> | > >> The proposed design does have two benefits though: | > >> * The new design requires fewer GHC extensions (no need for | `DefaultSignatures`) | > >> * It encourages programmers to use `DeriveLift`, which is shorter, | safer, and more direct. | > >> | > >> -Iavor | > >> | > >> | > >> | > >>> On Mon, Nov 5, 2018 at 10:50 AM Richard Eisenberg | wrote: | > >>> Will this break existing code? The proposal suggests that liftTyped | will have a suitable default implementation. | > >>> | > >>> Actually, this will break code, but not in the way one might think | (with an undefined liftTyped). Instead, the proposal removes the default | implementation of lift to use liftTyped. This means that any code relying | on the default implementation of lift will now have an instance with | mutually recursive, non-terminating methods. And this will all be silent. | And, it's something that might be discovered only in clients of a library, | rather than in the library itself. So I think that's pretty problematic. | Even with our recommendation to derive Lift instances, this change in | behavior is so terrible that it makes me lean against the proposal. Is | there a design / migration path that avoids this problem? | > >>> | > >>> (Yes, yes, I know that I could voiced this opinion earlier, but it | > >>> didn't occur to me until just now.) | > >>> | > >>> Richard | > >>> | > >>> > On Nov 5, 2018, at 1:37 PM, Ben Gamari wrote: | > >>> > | > >>> > Hi everyone, | > >>> > | > >>> > I have been asked to Shepard #175, which proposes to add a | > >>> > `liftTyped` method to the `Lift` typeclass used to lift Haskell | > >>> > values into Template Haskell splices. Currently the `Lift` | > >>> > typeclass provides no guarantee of type-safety, even when used in a | Typed Template Haskell context. | > >>> > | > >>> > The proposal resolves this limitation by adding a typed lifting | > >>> > operation to the `Lift` class: | > >>> > | > >>> > class Lift t where | > >>> > lift :: t -> Q Exp | > >>> > liftTyped :: t -> Q (TExp t) | > >>> > | > >>> > While this addition will break manually-written `Lift` | > >>> > instances, we recommended that users derive such instances for | > >>> > quite a while now, so it is not expected that the breakage will | > >>> > be wide-spread. In light of this, I recommend that we accept this | proposal. | > >>> > | > >>> > Given that we will likely want to get this in to 8.8, I suggest | > >>> > that we limit the discussion to a week unless there is dissent. | > >>> > | > >>> > Cheers, | > >>> > | > >>> > - Ben | > >>> > _______________________________________________ | > >>> > ghc-steering-committee mailing list | > >>> > ghc-steering-committee at haskell.org | > >>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c | > >>> > ommittee | > >>> | > >>> _______________________________________________ | > >>> ghc-steering-committee mailing list | > >>> ghc-steering-committee at haskell.org | > >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-com | > >>> mittee | > > | > > _______________________________________________ | > > ghc-steering-committee mailing list | > > ghc-steering-committee at haskell.org | > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commi | > > ttee | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From eric at seidel.io Wed Dec 19 10:49:59 2018 From: eric at seidel.io (Eric Seidel) Date: Wed, 19 Dec 2018 05:49:59 -0500 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: References: <87zhunv09p.fsf@smart-cactus.org> <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> <592230B0-33F9-468F-8676-F6DED97E49CE@seidel.io> <1545190628.935552.1613138120.0DE606A9@webmail.messagingengine.com> Message-ID: <1545216599.1040104.1613362848.19A543DA@webmail.messagingengine.com> Joachim wrote: > I think 1. is at odds in GHC – we allow partiality in other places as > well (partially initialized records, for example). Disallowing it feels > like a too fundamental change to the language for the problem we need > to solve here. Yes, I agree that changing the semantics of MINIMAL solely to fix this issue is not a great idea. But having a MINIMAL violation be a warning instead of an error generally feels shady to me. The only use of MINIMAL pragmas I've seen is to break mutually recursive definitions. That means there's an important difference between MINIMAL pragmas and other sources of partiality. In a partial record construction, your program will be fine so long as you don't access the uninitialized fields. This is dangerous, so we warn you about it, but it's still possible that your program will be correct. With a MINIMAL violation, it seems like the programmer is telling us that an instance *cannot* be correct unless it provides the minimal definitions. But I shouldn't derail the conversation.. Perhaps I'll write up a separate proposal about MINIMAL. > 3. is a neat idea, but again a very big cannon for a niche problem. If > we _had_ ghc-fix, then this might be a good approach, and we can keep > this in mind as additional evidence that ghc-fix would be good (GSOC > anyone), but let's not wait for that here. Indeed, I wouldn't make this wait on ghc-fix either, but it would be a very nice thing to have right now! > 2. is good, I think. We have had plenty of such kludges, e.g. around > the Monad refactoring. If we're ok with kludges like this to ease the migration, I think it's clearly the simplest solution. --- Simon wrote: > Is there any reason for not adopting the second alternative in section 5: make liftTyped the sole method of Lift? I suspect this would break more code than the current proposal, since you do sometimes have to write a manual `lift` instance (eg if you have a field like Text that doesn't have an instance). Fixing such code would also require CPP, which we usually try to avoid. From rae at cs.brynmawr.edu Sat Dec 22 03:04:01 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 21 Dec 2018 22:04:01 -0500 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <1545216599.1040104.1613362848.19A543DA@webmail.messagingengine.com> References: <87zhunv09p.fsf@smart-cactus.org> <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> <592230B0-33F9-468F-8676-F6DED97E49CE@seidel.io> <1545190628.935552.1613138120.0DE606A9@webmail.messagingengine.com> <1545216599.1040104.1613362848.19A543DA@webmail.messagingengine.com> Message-ID: <5152A0BE-E7B9-489A-A7C7-8C5BCAE01E0C@cs.brynmawr.edu> I favor Simon's suggestion. Just rip out `lift` from the class and define it as a top-level function. This breaks backward-compat, but in an inescapable way. And TH users are accustomed to breakage. My problem earlier wasn't just that it wasn't backward-compatible, but that it was incompatible in such a terrible way. Simon's suggestion leads to a better incompatibility. Richard > On Dec 19, 2018, at 5:49 AM, Eric Seidel wrote: > > Joachim wrote: >> I think 1. is at odds in GHC – we allow partiality in other places as >> well (partially initialized records, for example). Disallowing it feels >> like a too fundamental change to the language for the problem we need >> to solve here. > > Yes, I agree that changing the semantics of MINIMAL solely to fix this issue is not a great idea. But having a MINIMAL violation be a warning instead of an error generally feels shady to me. > > The only use of MINIMAL pragmas I've seen is to break mutually recursive definitions. That means there's an important difference between MINIMAL pragmas and other sources of partiality. In a partial record construction, your program will be fine so long as you don't access the uninitialized fields. This is dangerous, so we warn you about it, but it's still possible that your program will be correct. With a MINIMAL violation, it seems like the programmer is telling us that an instance *cannot* be correct unless it provides the minimal definitions. > > But I shouldn't derail the conversation.. Perhaps I'll write up a separate proposal about MINIMAL. > >> 3. is a neat idea, but again a very big cannon for a niche problem. If >> we _had_ ghc-fix, then this might be a good approach, and we can keep >> this in mind as additional evidence that ghc-fix would be good (GSOC >> anyone), but let's not wait for that here. > > Indeed, I wouldn't make this wait on ghc-fix either, but it would be a very nice thing to have right now! > >> 2. is good, I think. We have had plenty of such kludges, e.g. around >> the Monad refactoring. > > If we're ok with kludges like this to ease the migration, I think it's clearly the simplest solution. > > --- > > Simon wrote: > >> Is there any reason for not adopting the second alternative in section 5: make liftTyped the sole method of Lift? > > I suspect this would break more code than the current proposal, since you do sometimes have to write a manual `lift` instance (eg if you have a field like Text that doesn't have an instance). Fixing such code would also require CPP, which we usually try to avoid. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee