[Template-haskell] How to extract name and type of exported functions in modules

[kahl at cas.mcmaster.ca]

Simon Peyton Jones wrote:

 > What is the info for an instance?
 > Do we need a way to ask for all the instances of a class
 > (or rules for a function)
 > regardless of what module those instances come from?   etc
 > 
 > 
 > Does this ring bells for anyone else?

It does --- but completely outside the context of Template-Haskell.

I have been trying to do things via the GHC API (the full API,
not just module GHC), and found it surprisingly hard to obtain
all exports for a given module
(whether source or compiled library module):

-- If it exports any prelude indentifiers (not only the Prelude itself,
   but also for example Data.List), I have no idea how to get at
   their types --- lookupGlobalName does not find them.

-- I cannot find any re-exported instances. The ``package InstEnv''
   obtained from tcGetInstEnvs after loading a library module interface
   (via findAndReadIface) seems to contain only the module's own exported
   instances, which are the same instances I also find via mi_insts.
   (For source modules, where I use typeCheckModule,
    I've only been able to find the module's own exported instances via
    hptInstances).

   Even while not counting the missing Prelude instances,
   Data.Map is still re-exporting the Data.Set instances from the same
   package --- where does GHC keep those?
   And where does it keep those from different packages?
   my current understanding of the ``home InstEnv'' is that it contains
   instances encountered during ``ghc --make'' that may not be visible in
   the current module, so if I ever do find instances there,
   how would I filter the visible ones?

 > Do we need a way to ask for all the instances of a class
 > (or rules for a function)
 > regardless of what module those instances come from?   etc

As long as a module re-exports an instance, I'd like to be able to find it
from that module.


 > For example, if module exports T( C1, C2), where C1, C2 are constructors
 > of T which also has constructors C3, C4, what should appear in
 > mi_exports?  Should mi_exports reflect the structure of the export list
 > (see the AvailInfo type in GHC).

Applications that look at a module ``from the outside''
should, in my opinion, not be able see C3 and C4.
I think they also do not need to be able to know
that there are additional constructors.
There is always _|_ that doesn't match C1 nor C2,
even if there are no C3 nor C4.

Applications that need to know more will want an interface
that allows to ``look at all the insides'' of a module,
i.e., they want access to all items defined and imported inside,
and may of course also want to know which of these items are exported.

Since there are other interfaces to find out that C1 and C2 belong to T,
I don't think it is essential to know the structure of the export list.
It may be convenient, though...

(By the way, IIRC, sometimes I can import C1 as ``C1'',
 and sometimes I need to import it as ``T(C1)''.
 Is this a side effect of some LANGUAGE extension?)


Wolfram