From mail at joachim-breitner.de Mon Nov 5 13:53:05 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 05 Nov 2018 14:53:05 +0100 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: <1198a2993a4ce541058f70392185673799c9d0fe.camel@joachim-breitner.de> Hi, looks like we are rejecting this. Christopher, would you care to close the pull request with a nice and constructive message for the authors? Thanks, Joachim Am Sonntag, den 30.09.2018, 21:08 -0400 schrieb Richard Eisenberg: > 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 > > _______________________________________________ > 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/ -------------- 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 Mon Nov 5 13:58:50 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 05 Nov 2018 14:58:50 +0100 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: Hi, Am Dienstag, den 09.10.2018, 16:45 -0400 schrieb Eric Seidel: > I recommend we accept the proposal. 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 cma at bitemyapp.com Mon Nov 5 13:59:01 2018 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 5 Nov 2018 07:59:01 -0600 Subject: [ghc-steering-committee] Bundling patterns with type synonyms (#28) In-Reply-To: <1198a2993a4ce541058f70392185673799c9d0fe.camel@joachim-breitner.de> References: <61FD037C-4A8F-45F2-A0E1-9010380F8029@cs.brynmawr.edu> <08573db359ccbefa07080c28884667d56bde207d.camel@joachim-breitner.de> <1198a2993a4ce541058f70392185673799c9d0fe.camel@joachim-breitner.de> Message-ID: <9850B20F-A3EF-4C8F-BF1A-714BE01A13A8@bitemyapp.com> I'll try to gather up the principal reasons for rejection and do so, thank you! > On Nov 5, 2018, at 07:53, Joachim Breitner wrote: > > Hi, > > looks like we are rejecting this. Christopher, would you care to close > the pull request with a nice and constructive message for the authors? > > Thanks, > Joachim > > Am Sonntag, den 30.09.2018, 21:08 -0400 schrieb Richard Eisenberg: >> 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 >> >> _______________________________________________ >> 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 From mail at joachim-breitner.de Mon Nov 5 14:05:33 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 05 Nov 2018 15:05:33 +0100 Subject: [ghc-steering-committee] Proposal #170: Unrestricted OverloadedLabels (was: Uppercase OverloadedLabels), rec: accept In-Reply-To: References: Message-ID: <7e1751c44591b19c7c322fc48a595f6c63e559a3.camel@joachim-breitner.de> Hi, Am Samstag, den 20.10.2018, 09:39 -0700 schrieb Vitaly Bragilevsky: > Please speak up within a week if you have any concerns. Silence is understood as agreement. Booming silence. 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 Mon Nov 5 14:08:28 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 05 Nov 2018 15:08:28 +0100 Subject: [ghc-steering-committee] Discussion: List instances for a type in GHCi #166 In-Reply-To: <21E0BBB5-FE62-4620-983D-A928A230A70A@cs.brynmawr.edu> References: <21E0BBB5-FE62-4620-983D-A928A230A70A@cs.brynmawr.edu> Message-ID: <28259413050c513d4d15875dcb8b1aeabf6293d5.camel@joachim-breitner.de> And nobody disagrees… accepted Cheers, Joachim Am Montag, den 29.10.2018, 00:16 -0400 schrieb Richard Eisenberg: > 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 > > _______________________________________________ > 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/ -------------- 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 Mon Nov 5 14:12:43 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 05 Nov 2018 15:12:43 +0100 Subject: [ghc-steering-committee] Status Message-ID: Dear committee, This was a quiet, but very productive month. Since the last status update, we * were asked to review these proposals: #173 The dot type operator (shepherd: Eric) #174 lower precedence for UNPACK (shepherd: Joachim) #166 List instances in ghci (shepherd: Iavor) #175 liftTyped (shepherd: Ben) * got a recommendation from shepherds about: #170 Unrestricted OverloadedLables (rec: accept) #28 Bundling patterns with type synonyms (rec changed to reject) #174 lower precedence for UNPACK (rec: accept) #173 The dot type operator (rec: accept) #111 Linear types (rec: conditional accept) #166 List instances in ghci (rec: accept) * decided about the following proposals #174 lower precedence for UNPACK (accept) #168 fail with Overloaded Strings (accept) #173 The dot type operator (accept) #170 Unrestricted OverloadedLables (accept) #111 Linear types (rec: conditional accept) #166 List instances in ghci (accept) We currently have to act on the following 6 proposals, 3 less than last round, continuing a pleasant downward trend. liftTyped https://github.com/ghc-proposals/ghc-proposals/pull/175 Shepherd: Ben Status: Waiting for 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, what is the status of discussion? Or-Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Recommendation: accept Status: Round 2 discussion ebbed down. Manuel? Bundling patterns with synonyms https://github.com/ghc-proposals/ghc-proposals/pull/28 Shepherd: Chris Recommendation: reject Status: Rejection imminent 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 Mon Nov 5 18:15:08 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 5 Nov 2018 10:15:08 -0800 Subject: [ghc-steering-committee] Please review #175: Lift.liftTyped, Shepherd: Ben Gamari In-Reply-To: References: Message-ID: Hello, I know Ben is the shepherd for this and we have not started an official discussion, but I'd like to suggest that we accept it. My reasoning is that it is 1) a simple change, 2) which would be quite useful if you use typed TH, and 3) I can't really think of any downsides to it. -Iavor On Mon, Oct 15, 2018 at 3:09 PM Joachim Breitner wrote: > 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/ > > _______________________________________________ > 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 ben at well-typed.com Mon Nov 5 18:22:45 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 05 Nov 2018 13:22:45 -0500 Subject: [ghc-steering-committee] Please review #175: Lift.liftTyped, Shepherd: Ben Gamari In-Reply-To: References: Message-ID: <8736sfwfin.fsf@smart-cactus.org> Iavor Diatchki writes: > Hello, > > I know Ben is the shepherd for this and we have not started an official > discussion, but I'd like to suggest that we accept it. > My reasoning is that it is 1) a simple change, 2) which would be quite > useful if you use typed TH, and 3) I can't really think of any downsides > to it. > Yikes! I somehow missed this. Thanks for kicking off the discussion, Iavor. I will send a formal introduction right now. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Mon Nov 5 18:37:27 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 05 Nov 2018 13:37:27 -0500 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) Message-ID: <87zhunv09p.fsf@smart-cactus.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rae at cs.brynmawr.edu Mon Nov 5 18:50:48 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 5 Nov 2018 13:50:48 -0500 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <87zhunv09p.fsf@smart-cactus.org> References: <87zhunv09p.fsf@smart-cactus.org> Message-ID: 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 From eric at seidel.io Mon Nov 5 19:51:50 2018 From: eric at seidel.io (Eric Seidel) Date: Mon, 05 Nov 2018 14:51:50 -0500 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: References: <87zhunv09p.fsf@smart-cactus.org> Message-ID: <1541447510.2199026.1566526920.62BE741B@webmail.messagingengine.com> On Mon, Nov 5, 2018, at 13:50, 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? The current iteration of the proposal has a MINIMAL pragma on Lift, specifying that either lift or liftTyped must be explicitly implemented. https://github.com/harpocrates/ghc-proposals/blob/lift-typed/proposals/0000-lift-typed.rst#2proposed-change-specification So code that currently relies on the default implementation of lift will indeed break, but not silently! The library author will get a warning that they need to provide lift or liftTyped (or, preferably, switch to DeriveLift). From eric at seidel.io Mon Nov 5 20:26:49 2018 From: eric at seidel.io (Eric Seidel) Date: Mon, 5 Nov 2018 13:26:49 -0700 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <1541447510.2199026.1566526920.62BE741B@webmail.messagingengine.com> References: <87zhunv09p.fsf@smart-cactus.org> <1541447510.2199026.1566526920.62BE741B@webmail.messagingengine.com> Message-ID: <9D6813F2-1CAA-4A06-AA34-C28CE989C646@seidel.io> Though on second thought, this still doesn’t exactly provide a clean migration path. If I depend on version X of some library that uses the default implementation of lift, and I upgrade to a new GHC with the new Lift class, version X of my dependency will continue to compile, albeit with a warning. But I probably don’t pay much attention to warnings in my dependencies (and almost certainly don’t compile them with -Werror), so I may still be caught off-guard by the change. Sent from my iPhone > On Nov 5, 2018, at 12:51, Eric Seidel wrote: > >> On Mon, Nov 5, 2018, at 13:50, 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? > > The current iteration of the proposal has a MINIMAL pragma on Lift, specifying that either lift or liftTyped must be explicitly implemented. > > https://github.com/harpocrates/ghc-proposals/blob/lift-typed/proposals/0000-lift-typed.rst#2proposed-change-specification > > So code that currently relies on the default implementation of lift will indeed break, but not silently! The library author will get a warning that they need to provide lift or liftTyped (or, preferably, switch to DeriveLift). From iavor.diatchki at gmail.com Mon Nov 5 23:31:54 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 5 Nov 2018 15:31:54 -0800 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: References: <87zhunv09p.fsf@smart-cactus.org> Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Nov 7 16:40:26 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 7 Nov 2018 11:40:26 -0500 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: References: <87zhunv09p.fsf@smart-cactus.org> Message-ID: <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Wed Nov 7 17:45:58 2018 From: eric at seidel.io (Eric Seidel) Date: Wed, 7 Nov 2018 11:45:58 -0600 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> References: <87zhunv09p.fsf@smart-cactus.org> <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> Message-ID: <592230B0-33F9-468F-8676-F6DED97E49CE@seidel.io> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: