From iavor.diatchki at gmail.com Tue Jan 8 23:10:01 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 8 Jan 2019 15:10:01 -0800 Subject: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`" In-Reply-To: References: Message-ID: Hello, does anyone else have any input on this proposal? There has been some discussion on Simon's point about using a type-family instead of a fun-dep. The outcome of the discussion is a little unclear, but here is a very brief summary to the best of my understanding: * Either approach works, but with the current GHC implementations both approaches have some pros and some cons. * Fun-deps (used in the current design) are a bit more restrictive as they do not produce evidence at the moment * There are two ways to use type families instead of fun-deps: a) the class has 2 parameters, and the third is computed from them using a type family b) the class remains with 3 parameters, but it gets a super-class constraint, where a type-family encodes the functional dependency * Either type family encoding leads to types that look more verbose, both in errors and inferred types. * There are some ideas about how this might be improved for type families in general (see #16070) The choice of type-families/fun-deps is quite orthogonal to the original proposal, which is about adding a way to update records. We were discussing it, because it is quite tempting to roll-up multiple interface breaking changes into one. In the interest of making progress, my vote would be to accept the proposal as is, and delay switching to type families to a separate proposal, which might look better once the improvements in #16070 are figured out. What does everyone else think? -Iavor On Wed, Dec 19, 2018 at 1:04 AM Simon Peyton Jones wrote: > 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 simonpj at microsoft.com Tue Jan 8 23:46:34 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 8 Jan 2019 23:46:34 +0000 Subject: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`" In-Reply-To: References: Message-ID: Yes, I’m fine with accepting as-is. Actually the discussion has been quite illuminating. I learned * An idea for improving inferred types (Trac #16070) * An understanding that * Type families are in some ways more expressive because they support evidence * But fundeps allow overlap (which for soundness type families must eschew) and that allows a different kind of expressiveness. So the two overlap, but neither subsumes the other. And I think the choice is fundamental; the overlap stuff in fundeps is allowed precisely because it only affect unification, and doesn’t turn into evidence. * For HasField we don’t need overlap. * However, even if we used a type-family encoding, a 3-parameter class is probably best, because it leads to briefer types. * And, absent #16070, the error messages with fundeps are better, and the extra expressiveness of type families has not (yet) become important for HasField. Conclusion: use fundeps for now. Simon From: Iavor Diatchki Sent: 08 January 2019 23:10 To: Simon Peyton Jones Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`" Hello, does anyone else have any input on this proposal? There has been some discussion on Simon's point about using a type-family instead of a fun-dep. The outcome of the discussion is a little unclear, but here is a very brief summary to the best of my understanding: * Either approach works, but with the current GHC implementations both approaches have some pros and some cons. * Fun-deps (used in the current design) are a bit more restrictive as they do not produce evidence at the moment * There are two ways to use type families instead of fun-deps: a) the class has 2 parameters, and the third is computed from them using a type family b) the class remains with 3 parameters, but it gets a super-class constraint, where a type-family encodes the functional dependency * Either type family encoding leads to types that look more verbose, both in errors and inferred types. * There are some ideas about how this might be improved for type families in general (see #16070) The choice of type-families/fun-deps is quite orthogonal to the original proposal, which is about adding a way to update records. We were discussing it, because it is quite tempting to roll-up multiple interface breaking changes into one. In the interest of making progress, my vote would be to accept the proposal as is, and delay switching to type families to a separate proposal, which might look better once the improvements in #16070 are figured out. What does everyone else think? -Iavor On Wed, Dec 19, 2018 at 1:04 AM Simon Peyton Jones > wrote: 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 marlowsd at gmail.com Wed Jan 9 08:18:58 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 9 Jan 2019 08:18:58 +0000 Subject: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`" In-Reply-To: References: Message-ID: I defer to Simon's judgement on the details, however there's one point that I think should be mentioned - unless we get some significant benefit from using fundeps here, my preference would be to use type families instead purely because it's one fewer extension for people to understand, and this is core functionality that many people will likely encounter. Fundeps are much less widely used than type families, and it would be nice if we could keep them out of core abstractions so that those who don't need them don't need to learn about them. Cheers Simon On Tue, 8 Jan 2019 at 23:46, Simon Peyton Jones via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > Yes, I’m fine with accepting as-is. Actually the discussion has been > quite illuminating. I learned > > > > - An idea for improving inferred types (Trac #16070) > - An understanding that > - Type families are in some ways more expressive because they > support evidence > - But fundeps allow overlap (which for soundness type families must > eschew) and that allows a different kind of expressiveness. > > So the two overlap, but neither subsumes the other. And I think the > choice is fundamental; the overlap stuff in fundeps is allowed precisely > because it only affect unification, and doesn’t turn into evidence. > > - For HasField we don’t need overlap. > - However, even if we used a type-family encoding, a 3-parameter class > is probably best, because it leads to briefer types. > - And, absent #16070, the error messages with fundeps are better, and > the extra expressiveness of type families has not (yet) become important > for HasField. > > > > Conclusion: use fundeps for now. > > > > Simon > > > > *From:* Iavor Diatchki > *Sent:* 08 January 2019 23:10 > *To:* Simon Peyton Jones > *Cc:* ghc-steering-committee > *Subject:* Re: [ghc-steering-committee] Discussion for #158 "Add > `setFild` to `HasField`" > > > > Hello, > > > > does anyone else have any input on this proposal? > > > > There has been some discussion on Simon's point about using a type-family > instead of a fun-dep. The outcome of the discussion is a little unclear, > but here is a very brief summary to the best of my understanding: > > * Either approach works, but with the current GHC implementations both > approaches have some pros and some cons. > > * Fun-deps (used in the current design) are a bit more restrictive as > they do not produce evidence at the moment > > * There are two ways to use type families instead of fun-deps: > > a) the class has 2 parameters, and the third is computed from > them using a type family > > b) the class remains with 3 parameters, but it gets a > super-class constraint, where a type-family encodes the functional > dependency > > * Either type family encoding leads to types that look more verbose, > both in errors and inferred types. > > * There are some ideas about how this might be improved for type > families in general (see #16070) > > > > The choice of type-families/fun-deps is quite orthogonal to the original > proposal, which is about adding a way to update records. We were > discussing it, > > because it is quite tempting to roll-up multiple interface breaking > changes into one. > > > > In the interest of making progress, my vote would be to accept the > proposal as is, and delay switching to type families to a separate proposal, > > which might look better once the improvements in #16070 are figured out. > > > > What does everyone else think? > > > > -Iavor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Dec 19, 2018 at 1:04 AM Simon Peyton Jones > wrote: > > 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 > > _______________________________________________ > 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 iavor.diatchki at gmail.com Tue Jan 15 19:03:02 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 15 Jan 2019 11:03:02 -0800 Subject: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`" In-Reply-To: References: Message-ID: Hello, I am skeptical about the supposed overlap provided by functional dependencies that would be unsound with type families. It would be extremely odd to accept a "functional" dependency that is not functional. And if it is functional, then it should not be unsound to generate evidence for it. I am also not sure why one would use overlapping things for records---wouldn't that imply that a record has the same field multiple times somehow? So, for me, the overlap benefit of FDs is rather suspect and I imagine that if it works it is an artifact of the current implementation rather than something that has been thought about deeply. On the other hand, I do think that the FD formulation captures more precisely what is intended in this situation, as the relation between types and fields is inherently partial (i.e., not all types have all fields). As a result, if we used a type family, it would have to be a partial one. I know that these are commonly used, but I've never been quite comfortable with the way these "stuck" type families do not always result in a type error, and sometimes are treated silently as a ordinary types, even though they are not supposed to really correspond to any type at all. This does not happen with constraints, which always result in a type error, if they can't be solved. To summarize the current state of the discussion: - No one has complained about the main part of the proposal---adding an update functionality to the record class - Simon M would prefer to use a type family for the record field: Simon, which formulation are you thinking of, 2 or 3 parameter class? - Simon PJ would also prefer to use a type family, but due to some trade-offs is OK with using fun-deps for now. - Iavor would prefer to stick with fun-dpes for the reasons above (also, the change seems quite orthogonal to the proposal) I haven't heard from anyone else. While we are not in a big hurry, as I shepherd of this discussion I would like to move us in the direction of making a decision. So I am leaning towards accepting the proposal as is, unless Simon M or someone else objects strongly. If you do, please speak up soon. Cheers, -Iavor On Wed, Jan 9, 2019 at 12:19 AM Simon Marlow wrote: > I defer to Simon's judgement on the details, however there's one point > that I think should be mentioned - unless we get some significant benefit > from using fundeps here, my preference would be to use type families > instead purely because it's one fewer extension for people to understand, > and this is core functionality that many people will likely encounter. > Fundeps are much less widely used than type families, and it would be nice > if we could keep them out of core abstractions so that those who don't need > them don't need to learn about them. > > Cheers > Simon > > On Tue, 8 Jan 2019 at 23:46, Simon Peyton Jones via ghc-steering-committee > wrote: > >> Yes, I’m fine with accepting as-is. Actually the discussion has been >> quite illuminating. I learned >> >> >> >> - An idea for improving inferred types (Trac #16070) >> - An understanding that >> - Type families are in some ways more expressive because they >> support evidence >> - But fundeps allow overlap (which for soundness type families >> must eschew) and that allows a different kind of expressiveness. >> >> So the two overlap, but neither subsumes the other. And I think the >> choice is fundamental; the overlap stuff in fundeps is allowed precisely >> because it only affect unification, and doesn’t turn into evidence. >> >> - For HasField we don’t need overlap. >> - However, even if we used a type-family encoding, a 3-parameter >> class is probably best, because it leads to briefer types. >> - And, absent #16070, the error messages with fundeps are better, and >> the extra expressiveness of type families has not (yet) become important >> for HasField. >> >> >> >> Conclusion: use fundeps for now. >> >> >> >> Simon >> >> >> >> *From:* Iavor Diatchki >> *Sent:* 08 January 2019 23:10 >> *To:* Simon Peyton Jones >> *Cc:* ghc-steering-committee >> *Subject:* Re: [ghc-steering-committee] Discussion for #158 "Add >> `setFild` to `HasField`" >> >> >> >> Hello, >> >> >> >> does anyone else have any input on this proposal? >> >> >> >> There has been some discussion on Simon's point about using a type-family >> instead of a fun-dep. The outcome of the discussion is a little unclear, >> but here is a very brief summary to the best of my understanding: >> >> * Either approach works, but with the current GHC implementations both >> approaches have some pros and some cons. >> >> * Fun-deps (used in the current design) are a bit more restrictive as >> they do not produce evidence at the moment >> >> * There are two ways to use type families instead of fun-deps: >> >> a) the class has 2 parameters, and the third is computed from >> them using a type family >> >> b) the class remains with 3 parameters, but it gets a >> super-class constraint, where a type-family encodes the functional >> dependency >> >> * Either type family encoding leads to types that look more verbose, >> both in errors and inferred types. >> >> * There are some ideas about how this might be improved for type >> families in general (see #16070) >> >> >> >> The choice of type-families/fun-deps is quite orthogonal to the original >> proposal, which is about adding a way to update records. We were >> discussing it, >> >> because it is quite tempting to roll-up multiple interface breaking >> changes into one. >> >> >> >> In the interest of making progress, my vote would be to accept the >> proposal as is, and delay switching to type families to a separate proposal, >> >> which might look better once the improvements in #16070 are figured out. >> >> >> >> What does everyone else think? >> >> >> >> -Iavor >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Dec 19, 2018 at 1:04 AM Simon Peyton Jones >> wrote: >> >> 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 < >> ghc-steering-committee-bounces at haskell.org> *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 >> >> _______________________________________________ >> 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 mail at joachim-breitner.de Wed Jan 16 16:54:12 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 16 Jan 2019 17:54:12 +0100 Subject: [ghc-steering-committee] Status Message-ID: <469dc89e1742ba4e3ebd5e81c65708b085b8e4f1.camel@joachim-breitner.de> Dear committee, another quiet month. There are a few proposals that are desperately waiting for action from Manuel, Ben and Chris. Here is what happened: * were asked to review these proposals: -none- * got a recommendation from shepherds about: #158 Add setField to HasField (rec: accept) * decided about the following proposals -none- (But new, unsubmitted proposals are on the horizon.) We currently have to act on the following 6 proposals, down one because the Or pattern proposal got withdrawn. liftTyped https://github.com/ghc-proposals/ghc-proposals/pull/175 Shepherd: Ben Status: Acceptance recommended, more discussion happening, it seems. record-set-field proposal https://github.com/ghc-proposals/ghc-proposals/pull/158 Shepherd: Yav Status: Acceptance recommended, discussion about fundeps vs. tf. 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. 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 -------------- _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- 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 Sat Jan 19 16:59:46 2019 From: eric at seidel.io (Eric Seidel) Date: Sat, 19 Jan 2019 11:59:46 -0500 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <5152A0BE-E7B9-489A-A7C7-8C5BCAE01E0C@cs.brynmawr.edu> 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> <5152A0BE-E7B9-489A-A7C7-8C5BCAE01E0C@cs.brynmawr.edu> Message-ID: <1547917186.2586273.1638789112.522284A4@webmail.messagingengine.com> Let's try to pick this discussion back up. The proposal has been lingering on our end for a couple months now! We all seem to be in agreement that the basic proposal of adding `liftTyped` should be accepted. The discussion has mostly focused on backwards-compatibility concerns around the default implementation of `Lift`, specifically that the new mutually-recursive definitions of `lift` and `liftTyped` could break **clients** of libraries that use TH without even issuing a warning in the libraries themselves. There are two proposed solutions that seem to have some support. 1. I suggested a targeted warning/error about empty `Lift` instances that could be bundled with GHC. TH is bundled with GHC, so this would guarantee that we notify (or break) libraries before client code is affected. It would also let library authors avoid CPP while supporting multiple versions of TH. Joachim expressed his support for this solution. 2. The proposal suggests an alternative that replaces `lift` with `liftTyped` as the sole method of `Lift`. This is probably how we would design the `Lift` class today if we were starting from scratch. On the other hand, it forces library authors to use CPP to support multiple versions of TH, which people often try to avoid (e.g. due to tooling issues). Simon and Richard have expressed support for this solution. I would actually be happy with either solution. Joachim, are you happy with option 2? If so, perhaps we should just agree on it and move forward with the proposal. On Fri, Dec 21, 2018, at 22:04, Richard Eisenberg wrote: > 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 > From mail at joachim-breitner.de Sun Jan 20 09:30:14 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 20 Jan 2019 10:30:14 +0100 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <1547917186.2586273.1638789112.522284A4@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> <5152A0BE-E7B9-489A-A7C7-8C5BCAE01E0C@cs.brynmawr.edu> <1547917186.2586273.1638789112.522284A4@webmail.messagingengine.com> Message-ID: <16e0892e62f9865f435839e64f6f270b8c9c310c.camel@joachim-breitner.de> Hi, given that TH has never been the best when it comes to backwards compatibility, and if it is indeed how it should have been in the first place, then yup, fine with me. Cheers, Joachim Am Samstag, den 19.01.2019, 11:59 -0500 schrieb Eric Seidel: > Let's try to pick this discussion back up. The proposal has been lingering on our end for a couple months now! > > We all seem to be in agreement that the basic proposal of adding `liftTyped` should be accepted. The discussion has mostly focused on backwards-compatibility concerns around the default implementation of `Lift`, specifically that the new mutually-recursive definitions of `lift` and `liftTyped` could break **clients** of libraries that use TH without even issuing a warning in the libraries themselves. > > There are two proposed solutions that seem to have some support. > > 1. I suggested a targeted warning/error about empty `Lift` instances that could be bundled with GHC. TH is bundled with GHC, so this would guarantee that we notify (or break) libraries before client code is affected. It would also let library authors avoid CPP while supporting multiple versions of TH. Joachim expressed his support for this solution. > > 2. The proposal suggests an alternative that replaces `lift` with `liftTyped` as the sole method of `Lift`. This is probably how we would design the `Lift` class today if we were starting from scratch. On the other hand, it forces library authors to use CPP to support multiple versions of TH, which people often try to avoid (e.g. due to tooling issues). Simon and Richard have expressed support for this solution. > > I would actually be happy with either solution. > > Joachim, are you happy with option 2? If so, perhaps we should just agree on it and move forward with the proposal. > > On Fri, Dec 21, 2018, at 22:04, Richard Eisenberg wrote: > > 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 > _______________________________________________ > 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 Jan 21 09:24:10 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 21 Jan 2019 10:24:10 +0100 Subject: [ghc-steering-committee] Please review #167: Deprecated Entities, Shepherd: Vitaly Message-ID: Dear Committee, this is your secretary speaking: Adding namespaces to DEPRECATED has been proposed by Alex Dudarenko: https://github.com/ghc-proposals/ghc-proposals/pull/167 https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst I propose Vitaly Bragilevsky 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 eric at seidel.io Mon Jan 21 14:26:18 2019 From: eric at seidel.io (Eric Seidel) Date: Mon, 21 Jan 2019 09:26:18 -0500 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <16e0892e62f9865f435839e64f6f270b8c9c310c.camel@joachim-breitner.de> 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> <5152A0BE-E7B9-489A-A7C7-8C5BCAE01E0C@cs.brynmawr.edu> <1547917186.2586273.1638789112.522284A4@webmail.messagingengine.com> <16e0892e62f9865f435839e64f6f270b8c9c310c.camel@joachim-breitner.de> Message-ID: <1548080778.3965292.1639980320.5B41216D@webmail.messagingengine.com> Sounds like we have a consensus then. Ben, do you want to declare this proposal accepted (using the alternative of `liftTyped` as the sole method of `Lift`)? On Sun, Jan 20, 2019, at 04:30, Joachim Breitner wrote: > Hi, > > given that TH has never been the best when it comes to backwards > compatibility, and if it is indeed how it should have been in the first > place, then yup, fine with me. > > Cheers, > Joachim > > Am Samstag, den 19.01.2019, 11:59 -0500 schrieb Eric Seidel: > > Let's try to pick this discussion back up. The proposal has been lingering on our end for a couple months now! > > > > We all seem to be in agreement that the basic proposal of adding `liftTyped` should be accepted. The discussion has mostly focused on backwards-compatibility concerns around the default implementation of `Lift`, specifically that the new mutually-recursive definitions of `lift` and `liftTyped` could break **clients** of libraries that use TH without even issuing a warning in the libraries themselves. > > > > There are two proposed solutions that seem to have some support. > > > > 1. I suggested a targeted warning/error about empty `Lift` instances that could be bundled with GHC. TH is bundled with GHC, so this would guarantee that we notify (or break) libraries before client code is affected. It would also let library authors avoid CPP while supporting multiple versions of TH. Joachim expressed his support for this solution. > > > > 2. The proposal suggests an alternative that replaces `lift` with `liftTyped` as the sole method of `Lift`. This is probably how we would design the `Lift` class today if we were starting from scratch. On the other hand, it forces library authors to use CPP to support multiple versions of TH, which people often try to avoid (e.g. due to tooling issues). Simon and Richard have expressed support for this solution. > > > > I would actually be happy with either solution. > > > > Joachim, are you happy with option 2? If so, perhaps we should just agree on it and move forward with the proposal. > > > > On Fri, Dec 21, 2018, at 22:04, Richard Eisenberg wrote: > > > 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 > > _______________________________________________ > > 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 > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) From iavor.diatchki at gmail.com Tue Jan 22 18:41:27 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 22 Jan 2019 10:41:27 -0800 Subject: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`" In-Reply-To: References: Message-ID: Hello, I didn't hear any more thoughts on this one, so I will mark it as accepted. -Iavor On Tue, Jan 15, 2019 at 11:03 AM Iavor Diatchki wrote: > Hello, > > I am skeptical about the supposed overlap provided by functional > dependencies that would be unsound with type families. It would be > extremely odd to accept a "functional" dependency that is not functional. > And if it is functional, then it should not be unsound to generate evidence > for it. I am also not sure why one would use overlapping things for > records---wouldn't that imply that a record has the same field multiple > times somehow? So, for me, the overlap benefit of FDs is rather suspect > and I imagine that if it works it is an artifact of the current > implementation rather than something that has been thought about deeply. > > On the other hand, I do think that the FD formulation captures more > precisely what is intended in this situation, as the relation between types > and fields is inherently partial (i.e., not all types have all fields). > As a result, if we used a type family, it would have to be a partial one. > I know that these are commonly used, but I've never been quite comfortable > with the way these "stuck" type families do not always result in a type > error, and sometimes are treated silently as a ordinary types, even though > they are not supposed to really correspond to any type at all. This does > not happen with constraints, which always result in a type error, if they > can't be solved. > > To summarize the current state of the discussion: > - No one has complained about the main part of the proposal---adding an > update functionality to the record class > - Simon M would prefer to use a type family for the record field: > Simon, which formulation are you thinking of, 2 or 3 parameter class? > - Simon PJ would also prefer to use a type family, but due to some > trade-offs is OK with using fun-deps for now. > - Iavor would prefer to stick with fun-dpes for the reasons above > (also, the change seems quite orthogonal to the proposal) > > I haven't heard from anyone else. While we are not in a big hurry, as I > shepherd of this discussion I would like to move us in the direction of > making a decision. > > So I am leaning towards accepting the proposal as is, unless Simon M or > someone else objects strongly. If you do, please speak up soon. > > Cheers, > -Iavor > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 9, 2019 at 12:19 AM Simon Marlow wrote: > >> I defer to Simon's judgement on the details, however there's one point >> that I think should be mentioned - unless we get some significant benefit >> from using fundeps here, my preference would be to use type families >> instead purely because it's one fewer extension for people to understand, >> and this is core functionality that many people will likely encounter. >> Fundeps are much less widely used than type families, and it would be nice >> if we could keep them out of core abstractions so that those who don't need >> them don't need to learn about them. >> >> Cheers >> Simon >> >> On Tue, 8 Jan 2019 at 23:46, Simon Peyton Jones via >> ghc-steering-committee wrote: >> >>> Yes, I’m fine with accepting as-is. Actually the discussion has been >>> quite illuminating. I learned >>> >>> >>> >>> - An idea for improving inferred types (Trac #16070) >>> - An understanding that >>> - Type families are in some ways more expressive because they >>> support evidence >>> - But fundeps allow overlap (which for soundness type families >>> must eschew) and that allows a different kind of expressiveness. >>> >>> So the two overlap, but neither subsumes the other. And I think the >>> choice is fundamental; the overlap stuff in fundeps is allowed precisely >>> because it only affect unification, and doesn’t turn into evidence. >>> >>> - For HasField we don’t need overlap. >>> - However, even if we used a type-family encoding, a 3-parameter >>> class is probably best, because it leads to briefer types. >>> - And, absent #16070, the error messages with fundeps are better, >>> and the extra expressiveness of type families has not (yet) become >>> important for HasField. >>> >>> >>> >>> Conclusion: use fundeps for now. >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* Iavor Diatchki >>> *Sent:* 08 January 2019 23:10 >>> *To:* Simon Peyton Jones >>> *Cc:* ghc-steering-committee >>> *Subject:* Re: [ghc-steering-committee] Discussion for #158 "Add >>> `setFild` to `HasField`" >>> >>> >>> >>> Hello, >>> >>> >>> >>> does anyone else have any input on this proposal? >>> >>> >>> >>> There has been some discussion on Simon's point about using a >>> type-family instead of a fun-dep. The outcome of the discussion is a >>> little unclear, but here is a very brief summary to the best of my >>> understanding: >>> >>> * Either approach works, but with the current GHC implementations >>> both approaches have some pros and some cons. >>> >>> * Fun-deps (used in the current design) are a bit more restrictive as >>> they do not produce evidence at the moment >>> >>> * There are two ways to use type families instead of fun-deps: >>> >>> a) the class has 2 parameters, and the third is computed from >>> them using a type family >>> >>> b) the class remains with 3 parameters, but it gets a >>> super-class constraint, where a type-family encodes the functional >>> dependency >>> >>> * Either type family encoding leads to types that look more verbose, >>> both in errors and inferred types. >>> >>> * There are some ideas about how this might be improved for type >>> families in general (see #16070) >>> >>> >>> >>> The choice of type-families/fun-deps is quite orthogonal to the original >>> proposal, which is about adding a way to update records. We were >>> discussing it, >>> >>> because it is quite tempting to roll-up multiple interface breaking >>> changes into one. >>> >>> >>> >>> In the interest of making progress, my vote would be to accept the >>> proposal as is, and delay switching to type families to a separate proposal, >>> >>> which might look better once the improvements in #16070 are figured out. >>> >>> >>> >>> What does everyone else think? >>> >>> >>> >>> -Iavor >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Dec 19, 2018 at 1:04 AM Simon Peyton Jones < >>> simonpj at microsoft.com> wrote: >>> >>> 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 < >>> ghc-steering-committee-bounces at haskell.org> *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 >>> >>> _______________________________________________ >>> 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 cma at bitemyapp.com Sat Jan 26 19:11:15 2019 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 26 Jan 2019 12:11:15 -0700 Subject: [ghc-steering-committee] Bundling patterns with type synonyms (#28) In-Reply-To: References: Message-ID: I've replied to and closed the ticket with reasons for rejection. https://github.com/ghc-proposals/ghc-proposals/pull/28#issuecomment-457857005 On Wed, Jun 13, 2018 at 5:18 PM Christopher Allen wrote: > > The proposal I'm reviewing is: > > Bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski > > https://github.com/ghc-proposals/ghc-proposals/pull/28 > > Having reviewed the proposal and gone through some of the GHC Trac > history, 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. > > > Cheers, > Chris Allen -- Chris Allen Currently working on http://haskellbook.com From cma at bitemyapp.com Sat Jan 26 19:12:35 2019 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 26 Jan 2019 12:12:35 -0700 Subject: [ghc-steering-committee] Status In-Reply-To: <469dc89e1742ba4e3ebd5e81c65708b085b8e4f1.camel@joachim-breitner.de> References: <469dc89e1742ba4e3ebd5e81c65708b085b8e4f1.camel@joachim-breitner.de> Message-ID: I've addressed both proposals. Bundling patterns with synonyms is simply done unless you need to take further action with the rejection. ExtraCommas requires a final decision. I still think we should accept the proposal as-is and Matt is still prepared to move that ball forward. it's down to what the rest of the committee believes about the proposal's pros and cons. Cheers, Chris On Wed, Jan 16, 2019 at 9:54 AM Joachim Breitner wrote: > > Dear committee, > > another quiet month. There are a few proposals that are desperately > waiting for action from Manuel, Ben and Chris. > > Here is what happened: > > * were asked to review these proposals: > -none- > > * got a recommendation from shepherds about: > #158 Add setField to HasField (rec: accept) > > * decided about the following proposals > -none- > > (But new, unsubmitted proposals are on the horizon.) > > We currently have to act on the following 6 proposals, down one because > the Or pattern proposal got withdrawn. > > liftTyped > https://github.com/ghc-proposals/ghc-proposals/pull/175 > Shepherd: Ben > Status: Acceptance recommended, more discussion happening, it seems. > > record-set-field proposal > https://github.com/ghc-proposals/ghc-proposals/pull/158 > Shepherd: Yav > Status: Acceptance recommended, discussion about fundeps vs. tf. > > 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. > > 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/ > > _______________________________________________ > 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 -- Chris Allen Currently working on http://haskellbook.com From simonpj at microsoft.com Wed Jan 30 13:09:14 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 30 Jan 2019 13:09:14 +0000 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <1547917186.2586273.1638789112.522284A4@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> <5152A0BE-E7B9-489A-A7C7-8C5BCAE01E0C@cs.brynmawr.edu> <1547917186.2586273.1638789112.522284A4@webmail.messagingengine.com> Message-ID: I'm content with liftTyped. And while (2) is nicer ab-initio, it's not a big deal having two members of the class, so I'm fine with (1). Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Eric Seidel | Sent: 19 January 2019 17:00 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped | (recommendation: accept) | | Let's try to pick this discussion back up. The proposal has been | lingering on our end for a couple months now! | | We all seem to be in agreement that the basic proposal of adding | `liftTyped` should be accepted. The discussion has mostly focused on | backwards-compatibility concerns around the default implementation of | `Lift`, specifically that the new mutually-recursive definitions of | `lift` and `liftTyped` could break **clients** of libraries that use TH | without even issuing a warning in the libraries themselves. | | There are two proposed solutions that seem to have some support. | | 1. I suggested a targeted warning/error about empty `Lift` instances that | could be bundled with GHC. TH is bundled with GHC, so this would | guarantee that we notify (or break) libraries before client code is | affected. It would also let library authors avoid CPP while supporting | multiple versions of TH. Joachim expressed his support for this solution. | | 2. The proposal suggests an alternative that replaces `lift` with | `liftTyped` as the sole method of `Lift`. This is probably how we would | design the `Lift` class today if we were starting from scratch. On the | other hand, it forces library authors to use CPP to support multiple | versions of TH, which people often try to avoid (e.g. due to tooling | issues). Simon and Richard have expressed support for this solution. | | I would actually be happy with either solution. | | Joachim, are you happy with option 2? If so, perhaps we should just agree | on it and move forward with the proposal. | | On Fri, Dec 21, 2018, at 22:04, Richard Eisenberg wrote: | > 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-commi | > > ttee | > | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee