thenIO removal

Simon Peyton Jones simonpj at
Mon Nov 3 12:40:46 UTC 2014

It's not a big deal.  

You can probably replace both those bindIOName uses with bindMName (i.e (>>=)), in TcRnDriver.  That will just make GHCi generate code with uses of overloaded (>>=) that must be evaluated, rather than calling bindIO directly.  It should work just fine, but it'll make everything a tiny bit slower and more indirect.  If it simplified the code a lot, then fine, but it doesn't really.  So I'm inclined to leave it.


| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at] On Behalf Of Joachim
| Breitner
| Sent: 03 November 2014 08:22
| To: ghc-devs at
| Subject: Re: thenIO removal
| Hi,
| Am Sonntag, den 02.11.2014, 20:10 -0500 schrieb David Feuer:
| > GHC.Base has a function, thenIO, that isn't used anywhere in the
| > libraries or compiler, and isn't exported anywhere "public". But for
| > some reason, it's listed in compiler/prelude/PrelNames.lhs, which
| > causes a validation failure if I remove it. Is there a reason that a
| > completely unused function is wired in? Is it a historical artifact,
| > or an optimization that was never completed, or something else? Should
| > I wipe it out of PrelNames, or do we want to use it for something?
| I find uses in compiler/typecheck/TcRnDriver.lhs in tcUserStmt, it seems
| to be related to ghci’s support for IO actions. If you can rewrite that
| easily, then it surely can go, but there likely is a reason for it. If
| you find that reason, a Note would be appreciated.
| Greeting,
| Joachim
| --
| Joachim “nomeata” Breitner
|   mail at joachim-breitner.de
|   Jabber: nomeata at  • GPG-Key: 0xF0FBF51F
|   Debian Developer: nomeata at

More information about the ghc-devs mailing list