Using the GHC API: pretty printing with qualified names

[JP Moresmau]

Simon, thanks for the tips! I have changed the code to use nameModule_maybe
and I've verified that using that on a function imported through a qualified
import works.
Claus, Scott, the redirection from one standard package to a GHC package
wasn't my issue. We're in an IDE that uses GHC, so redirecting to the GHC
page instead of the Prelude page is not really an issue, it may just startle
some users. GHCi does the same:
Prelude> :info map
map :: (a -> b) -> [a] -> [b]   -- Defined in GHC.Base
Prelude> :info Prelude.map
map :: (a -> b) -> [a] -> [b]   -- Defined in GHC.Base

But I still would like to find a workaround to be able to jump to the
definition even after the type checking rewrite Simon explains, in GHC
6.10/12. I'll keep poking on how to get from that lambda function to the
real function it calls.

Thanks to all,

JP

On Thu, Nov 18, 2010 at 2:36 PM, <scooter.phd at gmail.com> wrote:

> Claus:
>
> 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.
>
>
> -scooter
> Sent from my Verizon Wireless BlackBerry
>
> -----Original Message-----
> 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:
>
>    http://trac.haskell.org/haddock/ticket/157
>
> Claus
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>


-- 
JP Moresmau
http://jpmoresmau.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20101118/b2f276c0/attachment.html