<div dir="ltr">Thank you both!</div><div class="gmail_extra"><br><div class="gmail_quote">On 10 June 2016 at 12:03, Adam Gundry <span dir="ltr"><<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/06/16 10:23, Niklas Hambüchen wrote:<br>
>> Now, I say 'trivial' since the actual fix is incredibly minor - a change<br>
>> of compose (.) to apply ($). What was less trivial was the (additional)<br>
>> hair loss arriving at the fix<br>
><br>
</span>> Tell me about it - when experimentally making a larger project work with<br>
> GHC 8, I spent a lot of time trying to understand the problem and was<br>
> rather disappointed that the climax of this effort was to replace `a = f<br>
> . g` by `a x = f (g x)` in two places.<br>
><br>
> The 8.0 migration guide<br>
> <a href="https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0</a> already has a<br>
> section about "Impredicative types brokenness" - I would have<br>
> appreciated if it contained the simple sentence "In many cases, this can<br>
> be fixed by rewriting `a = f . g` to `a x = f (g x)`."<br>
><br>
> Maybe somebody can add it.<br>
<br>
I've done so. Thanks for the suggestion!<br>
<span class=""><br>
<br>
>> * I assume previously GHC did not fully check type aliases that were<br>
>> impredictive prior to GHC 8?<br>
><br>
</span>> Yes,<br>
> <a href="https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0#Requirementforimpredicativetypes" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0#Requirementforimpredicativetypes</a>:<br>
> "In previous versions of GHC, it was possible to hide an impredicative<br>
> type behind a type synonym, because GHC did not always expand type<br>
> synonyms when checking for impredicativity."<br>
<span class="">><br>
>> * What does this imply for a type alias such as for the alias RunInBase<br>
>> used in monad-control that contains RankNTypes:<br>
>> <a href="http://hackage.haskell.org/package/monad-control-1.0.1.0/docs/Control-Monad-Trans-Control.html#t:RunInBase" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/monad-control-1.0.1.0/docs/Control-Monad-Trans-Control.html#t:RunInBase</a> -<br>
>> Is such an alias not safe in some sense? (Was it never safe?)<br>
><br>
</span>> I'll let others answer this one.<br>
<br>
The required extensions will depend on the use site. If RunInBase is<br>
used at the top level, no extensions should be needed. If it is used on<br>
the left-hand side of an arrow, RankNTypes will be required. If it is<br>
used as an argument to a type constructor (e.g. Maybe (RunInBase m b))<br>
then ImpredicativeTypes will be required. For example:<br>
<br>
    foo :: RunInBase m b          -- rank-1<br>
    bar :: RunInBase m b -> Bool  -- rank-2, needs RankNTypes<br>
    baz :: Maybe (RunInBase m b)  -- needs ImpredicativeTypes<br>
<br>
Previous versions of GHC may have accepted the third case without<br>
requiring ImpredicativeTypes in some circumstances, but this was a bug<br>
that made typechecking unpredictably dependent on when type synonyms get<br>
expanded (<a href="https://ghc.haskell.org/trac/ghc/ticket/10194" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/10194</a>).<br>
<br>
In general, RankNTypes is fairly safe in that its typing rules are<br>
fairly stable and well-understood. ImpredicativeTypes, on the other<br>
hand, is basically broken and should be avoided as far as possible.<br>
<br>
Hope this helps,<br>
<br>
Adam<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="http://www.well-typed.com/" rel="noreferrer" target="_blank">http://www.well-typed.com/</a><br>
</font></span></blockquote></div><br></div>