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

[Simon Peyton Jones]

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