A couple of GHC-API questions

[Richard Eisenberg]

Hi Eric,

This answer seems too easy, but I'll try anyway: are you looking for RnEnv.lookupOccRn :: RdrName -> RnM Name? According to the comments in the RdrName module, a RdrName is essentially a string with an optional module prefix. lookupOccRn will take a RdrName and convert it into a Name, which then can be lookup up perhaps a little more easily. You can use the RnM monad via functions in TcRnMonad.

Is this what you want?

Richard

On Jul 24, 2014, at 3:32 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Eric
> 
> I'd like to help but I don't understand the question.  What do you mean by "resolve" all the types that are imported from module A?  
> 
> If you have a TyCon (for A.Foo) in your hand, it has a Name. That Name tells you where it comes from. Inside it you will find its DataCons which also come from A.  And so on.
> 
> Later you say "is there a simple way to ask GHC to resolve the name x in the context of module m".  You could mean
> * Imagine that the unqualified name "x" appeared in module m.  How do I look it up, in m's top-level lexical environment.
> but I don’t think that is what you mean.
> 
> I'm confused. Could you be more concrete?
> Possibly this may help? https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/NameType
> 
> I'm cc'ing ghc-devs.  
> 
> Simon
> 
> | -----Original Message-----
> | From: Eric Seidel [mailto:eseidel at cs.ucsd.edu]
> | Sent: 23 July 2014 19:01
> | To: Simon Peyton Jones
> | Subject: A couple of GHC-API questions
> | 
> | Hi Simon,
> | 
> | I have a couple of questions about how to use GHC’s API properly.
> | There’s nothing urgent here as we’re making due just fine in
> | LiquidHaskell, but I’m pretty sure we’re hacking around GHC when we
> | don’t need to :)
> | 
> | As you probably know, we basically use GHC to get the Core binders of a
> | module, and to resolve a bunch of names. Translating to Core has never
> | been an issue for us as far as I know, but our name-resolution code is
> | very haphazard. The core of our problems with name-resolution comes
> | down to resolving the names in specifications that have been imported
> | from another module, e.g.
> | 
> |     module A where
> |     data Foo
> |     mkFoo :: {v:Int | v >= 0} -> Foo
> |     ...
> | 
> |     module B where
> |     import qualified A
> |     ...
> | 
> | When we verify module B we have to first resolve all of the types that
> | were imported from module A, *but* we can’t do that in the context of
> | module B due to the qualified import. So I’ve been using a slightly
> | modified version of GHC’s DynamicLoading.lookupRdrNameInModule to
> | handle the change of context, but this seems to require that we use the
> | HscInterpreted flag, which causes further problems for a few of our
> | benchmarks that make use of the C FFI.. This method also only works for
> | modules where we actually have the source code available, i.e. we have
> | to use a different method of looking up names to attach specifications
> | to functions from the base libraries.
> | 
> | So I guess my question is this: is there a simple way to ask GHC to
> | resolve the name x in the context of module m, without invoking the
> | code generator or any other part of GHC’s functionality? I suppose a
> | more principled solution would be to somehow hook into the .hi files
> | that GHC generates, but I’m not sure if that’s possible.
> | 
> | Again, the code we have right now works, it’s just very fragile and I’d
> | like to clean things up.
> | 
> | Thanks!
> | 
> | Eric
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>