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

[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