Using the GHC API: pretty printing with qualified names
scooter.phd at gmail.com
scooter.phd at gmail.com
Thu Nov 18 08:36:48 EST 2010
Respectfully, "No duh!" as schoolkids here in the US like to say when someone points out the obvious to them.
And "impossible" is the right word since the predicate evaluates to a boolean. Since false is the outcome, "impossible" refers correctly to the status of fetching the documentation.
Yes, we've been looking at the GHC sources. Why else would the question be posed with regard to "is there a better way of doing this?" Personally, I've had my fun re-implementing cabal package reading, and recreating someone else's work is counterproductive.
Sent from my Verizon Wireless BlackBerry
From: "Claus Reinke" <claus.reinke at talk21.com>
Date: Thu, 18 Nov 2010 10:53:05
To: <scooter.phd at gmail.com>; <glasgow-haskell-users at haskell.org>
Subject: Re: Using the GHC API: pretty printing with qualified names
> scion-server mimics a GHCi command line, of sorts. scion-server
> is used very successfully to syntax-highlight the Eclipse editor,
> show a source's outline, provide type information when hovering
> over a name, and provide completions.
> That's not the problem, per se. Let's say I'm hovering over a
> function that's imported by Data.Map. When resolved, the
> symbols appear to come from Ghc.Map (if memory serves
> correctly), which makes finding the correct "haddock" impossible.
"Impossible" is such an ugly word;-)
The problem you encounter is that the GHC API is still, to a
large part, just an open window into what happens to be
in GHC. Since GHC's aims as a compiler differ from those
of IDEs, its exposed functionality will sometimes be too
limited to serve your purposes (eg, if GHC knows where
a function is defined, it doesn't need to know how it was
imported, once it gets past error reporting).
If you tie yourself too closely to GHC's view, some things
you'd like to do in an IDE will _appear_ to be impossible.
That is why I recommend looking into the GHCi sources,
because GHCi's needs are closer to those of an IDE.
I assume you mean things like Data.List.map being a
re-exported GHC.List.map being a re-exported GHC.Base.map,
and :info not knowing about the intended abstractions:
Prelude> :i map
map :: (a -> b) -> [a] -> [b] -- Defined in GHC.Base
You can actually get information about possible import
paths via :browse!
Prelude> :m +Data.List
Prelude Data.List> :grep map|imported :browse!
-- imported via Data.List
mapAccumL :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y])
mapAccumR :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y])
-- imported via Data.List, Prelude
map :: (a -> b) -> [a] -> [b]
(:browse! is standard GHCi, :grep is non-standard, just to filter
:browse! output). So the :browse! command seems to be able
to find more of the information you want.
haskellmode for Vim, on the other hand, has long provided
haddock lookup, and will offer you a menu of possible
destinations when your cursor is over 'map'. This menu is
built from an index of Haddock entries, which is extracted
from installed Haddock documentation.
Nothing impossible about that, just ugly: so far, the index
is scraped from Haddock's HTML index files. That route
breaks occasionally (recent Haddock HTML changes,
ghc-pkg listing wrong Haddock paths, ..; I'm about to
publish updated scraping code for GHC-7.0.1's Haddock..).
To get something less ugly, I'm currently recoding the
extraction by using Haddock's API and .haddock files
(that'll still break when the API changes, also there is
a pending bug about ghc-pkg, cabal, and haddock
disagreeing about filepath formats, meaning that
.haddock files aren't found on Windows).
I assume that code will be useful to other Haskell IDEs,
though it is mostly exposing Haddock's internal ability to
build an index from .haddock files, which I'd like to see
exposed in Haddock's less-than-well-known API:
More information about the Glasgow-haskell-users