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

[Joachim Breitner]

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 <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-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: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190120/09836ca3/attachment.sig>