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

[Richard Eisenberg]

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