[ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept)

Wed May 1 21:30:07 UTC 2019

I think this proposal has been subsumed by https://github.com/ghc-proposals/ghc-proposals/pull/209.

On Wed, May 1, 2019, at 14:56, Joachim Breitner wrote:
> Hi,
> 
> I am bit lost here. Richard, do you feel confident to talk to the
> authors about the changes we are still waiting for (or just do them on
> the PR branch yourself), so that we can merge this accepted proposal?
> 
> Cheers,
> Joachim
> 
> Am Montag, den 11.02.2019, 16:20 -0500 schrieb Richard Eisenberg:
> > I see that you've posted acceptance, Ben. Thanks. But my understanding is that the accepted version was the one without `lift` in the class. Is that your understanding, too? If so, would you mind posting to the proposal author? (I think it's cleaner to have communication on this come from the shepherd.)
> > 
> > Thanks!
> > Richard
> > 
> > > On Jan 30, 2019, at 8:09 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> > > 
> > > 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 <ghc-steering-committee-bounces at haskell.org>
> > > > 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 <eric at seidel.io> 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
> > > _______________________________________________
> > > 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
> 
> Attachments:
> * signature.asc