I guess both items could be improved upon by extending GHCi to provide an additional `:def` facility tailored to Haskell symbols allowing to pass more meta-information (such as package and module information) into the resulting command string... would something like that have any chance of being accepted upstream?
I think it would make more sense to just add :doc to the GHCi front-end, relying on the user having already installed hoogle. We could give a sensible error message if you don't have Hoogle installed.
I think it would be awesome if you could extend GHCi's functionality with plug-ins. Mainly, because it would make it easy to experiment with ways to optimize your workflow. One use case I have in mind is running Hspec tests from GHCi. Currently that requires me to: (a) Reload the module: ghci> :reload (b) Check the output for compile errors. (c) Only if there were no compile errors, run the tests: ghci> hspec spec Here it would be nice to have a custom :hspec command within GHCi, that does all the required steps. But GHCi's current mechanism for defining commands is not powerful enough. (It's possible to define a sequence of commands, but it's not possible to check for the result of (a) and only conditionally do (c)).
From a users point of view I'd love to have a fancy GHCi monad to define commands (with access to all the built-ins, and means to define completion, etc.), and a mechanism to hook those commands into a running GHCi process.
How hard would it be to implement something like this? Cheers, Simon