Accessing the "original" names via GHC API

Ranjit Jhala jhala at cs.ucsd.edu
Wed Jan 25 14:14:40 UTC 2017


@Simon,

The route you outline was the one we already use -- but that gives back
the full name "Data.Set.Base.Set" (instead of "S.Set" or "Data.Set.Set"),
as the module is "Data.Set.Base".

@Edward,

Yes, I think your suggestion should work! This business of determining
which packages/modules are hidden is exactly what we are trying to get
around. (In this case, Data.Set.Base is hidden...)

Thanks all!

- Ranjit.


On Wed, Jan 25, 2017 at 1:00 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Hi Ranjit,
>
> Unfortunately you need more information to do this, since the
> set of modules which are available for import can vary depending
> on whether or not packages are hidden or not (not even counting
> whether or not a module is exposed or not!)
>
> The way GHC's pretty printer gives a good name is that it keeps
> track of all of the names in scope and where they came from
> in a GlobalRdrEnv.  The relevant code is in 'mkPrintUnqualified'
> in HscTypes, but if you pretty print using user-style with
> an appropriately set up GlobalRdrEnv you should
> get the things you want.
>
> Edward
>
> Excerpts from Ranjit Jhala's message of 2017-01-24 19:00:05 -0800:
> > Dear Joachim,
> >
> > You are right -- some more context.
> >
> > Given
> >
> >   tc  :: TyCon
> >   m   :: ModName
> >   env :: HscEnv
> >
> > I want to get a
> >
> >   s :: String
> >
> > such that _in_ the context given by `m` and `env` I can resolve `s` to
> get
> > back the original `TyCon`, e.g. something like
> >
> >   L _ rn <- hscParseIdentifier env s
> >   name   <- lookupRdrName env modName rn
> >
> > would then return `name :: Name` which corresponds to the original
> `TyCon`.
> >
> > That is, the goal is _not_ pretty printing, but "serialization" into a
> > String
> > representation that lets me recover the original `TyCon` later.
> >
> > (Consequently, `"Data.Set.Base.Set"` doesn't work as the `Data.Set.Base`
> > module is hidden and hence, when I try the above, GHC complains that the
> > name is not in scope.
> >
> > Does that clarify the problem?
> >
> > Thanks!
> >
> > - Ranjit.
> >
> >
> > On Tue, Jan 24, 2017 at 6:11 PM, Joachim Breitner <
> mail at joachim-breitner.de>
> > wrote:
> >
> > > Hi Ranjit,
> > >
> > > Am Dienstag, den 24.01.2017, 16:09 -0800 schrieb Ranjit Jhala:
> > > > My goal is to write a function
> > > >
> > > >    tyconString :: TyCon -> String
> > > >
> > > > (perhaps with extra parameters) such that given the
> > > > `TyCon` corresponding to `Set`, I get back the "original"
> > > > name `S.Set`, or even `Data.Set.Set`.
> > > >
> > > > Everything I've tried, which is fiddling with different variants of
> > > > `PprStyle`, end up giving me `Data.Set.Base.Set`
> > > >
> > > > Does anyone have a suggestion for how to proceed?
> > >
> > > in a way, `Data.Set.Base.Set` is the “original”, proper name for Set,
> > > everything else is just a local view on the name.
> > >
> > > So, are you maybe looking for a way to get the “most natural way” to
> > > print a name in a certain module context?
> > >
> > > This functionality must exist somewhere, as ghci is printing out errors
> > > this way. But it certainly would require an additional argument to
> > > tyconString, to specify in which module to print the name.
> > >
> > > Greetings,
> > > Joachim
> > >
> > >
> > > --
> > > Joachim “nomeata” Breitner
> > >   mail at joachim-breitner.dehttps://www.joachim-breitner.de/
> > >   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
> > >   Debian Developer: nomeata at debian.org
> > > _______________________________________________
> > > Glasgow-haskell-users mailing list
> > > Glasgow-haskell-users at haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170125/dafec278/attachment.html>


More information about the Glasgow-haskell-users mailing list