Re: API for looking-up/retrieving Haddock comments?
> >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
Re: API for looking-up/retrieving Haddock comments?
On 04/08/2012 08:33, Herbert Valerio Riedel wrote: Simon Hengel writes: [...] I have the following in my .ghci: -- hoogle integration :def hoogle \q -> return $ ":! hoogle --color=true --count=15 \"" ++ q ++ "\"" :def doc\q -> return $ ":! hoogle --color=true --info \"" ++ q ++ "\"" [...] thanks, this already looks very promising; there's just a few minor issues I'm a bit dissatisfied with the GHCi integration: 1. it doesn't take into account the currently visible module namespaces that GHCi has currently loaded (as opposed to `:info` and `:type`): , | Prelude> import Data.IntMap | | Prelude Data.IntMap> :info fromList | fromList :: [(Key, a)] -> IntMap a -- Defined in `Data.IntMap' | | Prelude Data.IntMap> :type fromList | fromList :: [(Key, a)] -> IntMap a | | Prelude Data.IntMap> :doc fromList | Searching for: fromList | Data.HashTable fromList :: Eq key => (key -> Int32) -> [(key, val)] -> IO (HashTable key val) | | Convert a list of key/value pairs into a hash table. Equality on keys | is taken from the Eq instance for the key type. | | From package base | fromList :: Eq key => (key -> Int32) -> [(key, val)] -> IO (HashTable key val) | | Prelude Data.IntMap> ` 2. tab-completion (as it works for `:type` and `:doc`) doesn't extend to `:doc` 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. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Non-updateable thunks
On 03/08/2012 10:29, Joachim Breitner wrote: Hi Simon, Am Freitag, den 03.08.2012, 09:28 +0100 schrieb Simon Marlow: My question is: Has anybody worked in that direction? And are there any fundamental problems with the current RTS implementation and such closures? Long ago GHC used to have an "update analyser" which would detect some thunks that would never be re-entered and omit the update frame on them. I wrote a paper about this many years ago, and there were other people working on similar ideas, some using types (e.g. linear types) - google for "update avoidance". As I understand it you want to omit doing some updates in order to avoid space leaks, which is slightly different. Thanks for the pointers, I will have a look. Why was the update analyser removed from GHC? It was expensive and had very little benefit - most thunks that were deemed non-updatable by the analysis were also strict, so update analysis did very little in the presence of strictness analysis. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
