On Fri, Feb 5, 2016 at 6:21 PM, Mike Izbicki
We're in a bit of a bind in all this. We really need the fancy type for ($) so that it can be used in all situations where it is used currently. The old type for ($) was just a plain old lie. Now, at least, we're not lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain growth because it affects how easy the language is to learn? I don't really think anyone is advocating for (3) exactly, but it's hard to have (2) and not make things more complicated -- unless we have a beginners' mode or other features in, say, GHCi that aid learning. As I've said, I'm in full favor of adding these features.
The old type for ($) is only a lie when the MagicHash extension is turned on. Otherwise, it is not a lie. I think the best solution is to pretty print the type depending on what language pragmas are in use. In GHCI, this would be trivial. The much harder case is haddock documentation.
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. You can instantiate both the source and target types of ($) to polytypes, not just monotypes. This lets us use ($) in situations like runST $ do ... 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. -Edward
I think a good way around this would be an eventual patch to haddock that allows the user to select which extensions they want to use when browsing documentation. There's a lot of usability issues that would need to be resolved with this still, but it reduces this technical discussion we're having down to a design discussion. It also nicely lets the user specify the level of difficulty they want their prelude to be without causing incompatibilty with users who want a different level of prelude. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs