
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I'm in support of acceptance and the quick transition strategy. One more bit of rationale: if we didn't have these features and someone proposed them today, we'd shoot them down without much discussion, given the way these features invisibly change the semantics of programs.<div class=""><br class=""></div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 17, 2020, at 2:16 PM, Eric Seidel <<a href="mailto:eric@seidel.io" class="">eric@seidel.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">I support acceptance as well. Changing the semantics of the program as part of type-checking is just bizarre and it seems like the impact in terms of required code changes is quite limited.</span><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Given how easy the fixes appear to be, and the fact that the fixed program will compile just fine with older GHCs, I'm inclined to support option (2): ripping the code out immediately. I've left a comment on the PR asking if we can do so while providing helpful fixit hints to unaware users.</span><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">On Fri, Jan 17, 2020, at 08:49, Spiwack, Arnaud wrote:</span><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" style="font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">Dear all,<br class=""><br class="">As the shepherd for proposal #287 [<span class="Apple-converted-space"> </span><br class=""><a href="https://github.com/ghc-proposals/ghc-proposals/pull/287" class="">https://github.com/ghc-proposals/ghc-proposals/pull/287</a> ], I recommend<span class="Apple-converted-space"> </span><br class="">acceptance<br class=""><br class="">Summary<br class=""><br class="">The proposal is to remove a bunch of typing rules meant to make<span class="Apple-converted-space"> </span><br class="">RankNTypes a bit more powerful (covariance and contravariance of the<span class="Apple-converted-space"> </span><br class="">arrow constructor, as well as deep instantiation and deep<span class="Apple-converted-space"> </span><br class="">skolemisation). The problem with these rules is that 1/ they complicate<span class="Apple-converted-space"> </span><br class="">the type checker 2/ They are implemented by performing eta-expansion<span class="Apple-converted-space"> </span><br class="">during elaboration, which changes the semantics of program 3/ Dropping<span class="Apple-converted-space"> </span><br class="">(some of) them is beneficial for the quick-look story (proposal<span class="Apple-converted-space"> </span><br class="">currently on hold).<br class=""><br class="">The authors have tried this change on all of Stackage, and could come<span class="Apple-converted-space"> </span><br class="">up with simple fixes (~300 lines of which) for all but 2 packages<span class="Apple-converted-space"> </span><br class="">(namely, singleton, because of template haskell stuff, and labels for<span class="Apple-converted-space"> </span><br class="">reason not well identified).<br class=""><br class="">Rationale<br class=""><br class="">The common point of all these features is that they jiggle the position<span class="Apple-converted-space"> </span><br class="">of foralls around. Which sounds reasonable at first glance. But really,<span class="Apple-converted-space"> </span><br class="">they tend to interact badly with other stuff (I don't remember the<span class="Apple-converted-space"> </span><br class="">circumstances, but there was a discussion of deep instantiation and<span class="Apple-converted-space"> </span><br class="">deep skolemisation in the context of linear types as well). Basically,<span class="Apple-converted-space"> </span><br class="">they are rather fragile features, I'd rather we did without them.<br class=""><br class="">I think that 300 lines of simple fixes for all of Stackage is a very<span class="Apple-converted-space"> </span><br class="">small number. So it is legitimate to consider this change to have low<span class="Apple-converted-space"> </span><br class="">impact. Regarding the singleton, I'm sure Richard will be happy to fix<span class="Apple-converted-space"> </span><br class="">it ;-) . Only labels remains. It shouldn't be a blocker.<br class=""><br class="">Remaining question<br class=""><br class="">There is one open question on the pull request thread. Namely, how to<span class="Apple-converted-space"> </span><br class="">schedule the removal. Two paths are being discussed<br class="">1. Add a `-XLessSubsumption` flag, turn it off by default, then turn<span class="Apple-converted-space"> </span><br class="">it on by default in version n+1, then remove the subsumption rules<span class="Apple-converted-space"> </span><br class="">altogether in version n+3<br class="">2. Simply remove the code, preferably early in the release cycle,<span class="Apple-converted-space"> </span><br class="">communicate profusely.<br class="">The thread participants seem to lean towards (2). The reason being that<span class="Apple-converted-space"> </span><br class="">this is a change where it is easy to write code compatible with<span class="Apple-converted-space"> </span><br class="">previous versions of the compiler (everything which compiles after this<span class="Apple-converted-space"> </span><br class="">change also compiles before this change). Also, there is a preference<span class="Apple-converted-space"> </span><br class="">for removing the relevant code sooner rather than later. But I'd like<span class="Apple-converted-space"> </span><br class="">the opinion of the committee.<br class=""><br class="">Best,<br class="">Arnaud<br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class=""><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class=""><br class=""></blockquote><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">ghc-steering-committee mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="mailto:ghc-steering-committee@haskell.org" style="font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">ghc-steering-committee@haskell.org</a><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" style="font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a></div></blockquote></div><br class=""></div></body></html>