> >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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users