<div dir="ltr"><div>Support seems unanimous so far. Unless someones voices a second opinion by then, I'll accept the proposal early next week.</div><div><br></div><div>Any other opinion on deprecation of `-XContravariantFunctions`? I'd like this to be planned and to have a schedule. Maybe, as Simon suggested in the Github thread, this should be another discussion, though?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 16, 2019 at 7:45 PM Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com">iavor.diatchki@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I haven't had time to read through this proposal, but I am comfortable<br>
accepting it based on the recommendations of others.<br>
<br>
On Mon, Oct 14, 2019 at 5:52 PM Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:<br>
><br>
> I support acceptance too, modulo a few small comments that I left on the GH discussion.<br>
><br>
> On Mon, Oct 14, 2019, at 02:53, Spiwack, Arnaud wrote:<br>
> > Dear all,<br>
> ><br>
> > As the title implies: I'm hereby recommending accepting the Quick look<br>
> > impredicativity proposal.<br>
> ><br>
> > Summary:<br>
> ><br>
> > The proposal modifies the `-XImpredicativeTypes` extension with a well<br>
> > defined semantics which consists in considering n-ary applications,<br>
> > rather than binary. And look, in such an application, for arguments<br>
> > which absolutely require impredicative instantiation (either<br>
> > universally quantified type applications, or arguments where a<br>
> > universal type is guarded by an invariant type constructor).<br>
> ><br>
> > In order to have the expected behaviour for `($)` and `(.)`, the<br>
> > proposal also makes the left-hand argument of the arrow invariant with<br>
> > respect to instantiation (currently: contravariant). The proposal is to<br>
> > make this change effective, even if `-XRankNTypes` is turned on, but<br>
> > not `-XImpredicativeTypes`. The proposal also introduces an extension<br>
> > `-XContravariantFunctions` to restore the old behaviour, for<br>
> > compatibility.<br>
> ><br>
> > Rational:<br>
> ><br>
> > `-XImpredicativeTypes` is a useful extension which is currently in a<br>
> > rather sad state. I'm happy to see it stabilise to a clear semantics.<br>
> > The semantics in the proposal covers a ton of use cases. It strikes a<br>
> > very good balance between usefulness and predictability.<br>
> ><br>
> > The use of n-ary application in the type system also has good<br>
> > theoretical roots: sequent calculi have n-ary applications. (in<br>
> > manyrespects, bidirectional type systems are also about n-ary<br>
> > application). So I don't consider it a wart at all.<br>
> ><br>
> > The propsal's semantics, including the absence of contravariant<br>
> > functions, goes in the direction of _guessing less things_. This is a<br>
> > direction that many GHC features have taken lately. I think it's a very<br>
> > very good direction! Guessing can be damaging for predictability, but.<br>
> > more importantly, guessing has a tendency to compose badly with other<br>
> > typing features. (it is to be noted, too, that the implementation of<br>
> > contravariant functions. in GHC, eta-expands the function, which can<br>
> > casually change its semantics, if the function was bottom).<br>
> ><br>
> > So, everything in this proposal does look good to me, except that, I<br>
> > think, I would like a deprecation route for the<br>
> > `-XContravariantFunctions` extension. Otherwise, we will be stuck with<br>
> > legacy code forever.<br>
> ><br>
> > Best,<br>
> > Arnaud<br>
> > _______________________________________________<br>
> > ghc-steering-committee mailing list<br>
> > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> ><br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>