<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 5, 2016 at 6:21 PM, Mike Izbicki <span dir="ltr"><<a href="mailto:mike@izbicki.me" target="_blank">mike@izbicki.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> We're in a bit of a bind in all this. We really need the fancy type for ($)<br>
> so that it can be used in all situations where it is used currently. The old<br>
> type for ($) was just a plain old lie. Now, at least, we're not lying. So,<br>
> do we 1) lie, 2) allow the language to grow, or 3) avoid certain growth<br>
> because it affects how easy the language is to learn? I don't really think<br>
> anyone is advocating for (3) exactly, but it's hard to have (2) and not make<br>
> things more complicated -- unless we have a beginners' mode or other<br>
> features in, say, GHCi that aid learning. As I've said, I'm in full favor of<br>
> adding these features.<br>
<br>
</span>The old type for ($) is only a lie when the MagicHash extension is<br>
turned on.  Otherwise, it is not a lie.  I think the best solution is<br>
to pretty print the type depending on what language pragmas are in<br>
use.  In GHCI, this would be trivial.  The much harder case is haddock<br>
documentation.<br></blockquote><div><br></div><div>Note: The old type of ($) has always been a lie, even without MagicHash, a much stronger lie because the true type of ($) can't even be written in the language today.</div><div><br></div><div>You can instantiate both the source and target types of ($) to polytypes, not just monotypes.</div><div><br></div><div>This lets us use ($) in situations like</div><div><br></div><div>runST $ do ...</div><div><br></div><div>Having it infer a RankNType through its magical type inference rule there doesn't require an extension on the behalf of the user, even if runST required them at the definition site.</div><div><br></div><div>-Edward</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think a good way around this would be an eventual patch to haddock<br>
that allows the user to select which extensions they want to use when<br>
browsing documentation.  There's a lot of usability issues that would<br>
need to be resolved with this still, but it reduces this technical<br>
discussion we're having down to a design discussion.  It also nicely<br>
lets the user specify the level of difficulty they want their prelude<br>
to be without causing incompatibilty with users who want a different<br>
level of prelude.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div></div>