[Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic
ekmett at gmail.com
Sat Feb 6 17:09:22 UTC 2016
On Fri, Feb 5, 2016 at 6:21 PM, Mike Izbicki <mike at 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
> > type for ($) was just a plain old lie. Now, at least, we're not lying.
> > 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
> > anyone is advocating for (3) exactly, but it's hard to have (2) and not
> > 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
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
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.
> 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 at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs