On Fri, Feb 5, 2016 at 6:21 PM, Mike Izbicki <m...@izbicki.me> wrote:
> > 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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs