October 2009 - template-haskell

How to extract name and type of exported functions in modules
by Oscar Finnsson 29 Oct '09

29 Oct '09

Hi, I'm trying to extract the names and types of exported functions in a module. At the moment I've managed to get a list of all functions in a module but I can't seem to figure out how to get their types. Lets say I got the module module Foo where foo1 :: String -> String foo1 value = value foo2 = "hej" and then in anothor module... module Bar where bar = $(getAllFunctions "<some-path>/Foo.hs") At the moment I got getAllFunctions returning ["foo1","foo2"], but I would really like to get it to return [("foo1",AppT (ConT "String") (ConT "String")), ("foo2",ConT "String")] Using "parseModuleWithMode" from Language.Haskell.Exts I can get hold of the names and the type signature of foo1 (since it's specified in the source code) but I cannot get hold of the type signature of foo2 (since it's not specified in the source code). Is there another way to get the names/signatures of exported functions from a module other than using parseModuleWithMode so the developer writing the Foo-module isn't forced to explicitly supply type signatures of the exported functions? If I try "reify" to get information about the functions I get the error message: "foo1 is not in scope at a reify" This seems to be a known bug about reify (reported here http://hackage.haskell.org/trac/ghc/ticket/2339) My problem is that I cannot use the workaround since I don't know the name of the functions. Another disadvantage with this approach is that "getAllFunctions" must have access to the source code of the module and that I must supply the path the the module. If possible I would like to have code such as bar = $(getAllFunctions "Foo") instead of "<come-path>/Foo.hs". Regards, Oscar Finnsson

3 4

Generating arithmetic expressions in TH
by Vitor Rodrigues 22 Oct '09

22 Oct '09

Hello, I am starting using TH to generate lambda expressions representing arithmetic expressions. My current problem is to generate code where all the lambda abstractions are in the top level. For example, I would like to have \x -> 1 + x instead of 1 + (\x -> x) My problem is that I don't know in beforehand if the second operand is a variable or not. If so, I would like to build a top level abstraction. It is this possible? Regards, Vitor

2 1

RE: [Template-haskell] How to extract name and type of exported functions in modules
by Simon Peyton-Jones 21 Oct '09

21 Oct '09

| -- 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. Well, it claims that it should find them. Would you like to make a reproducible test case and file a Trac bug report? | -- 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). Hmm. GHC does not read every interface file for every module in every package that is transitively visible from the current module. Instead it relies on the fact that before an instance (C T) is useful, you must have a hold of Class C and TyCon T. So you'll have loaded *their* interfaces, and thereby loaded their instances. (Except for orphan instances, which *are* loaded eagerly.) I can see that this is inconvenient; on the other hand, do you really want ALL the instances of Ord, say? Perhaps there should be an interface for load instances that relate to the following Names Indeed, there is: LoadIface.loadInterfaceForName. Does that help? What's the desired behaviour? I really wish there was someone who took ownership for the GHC API, as seen by "customers" of the API. At the moment it grows incrementally, without proper design. Maybe no one feels able to, because they think GHC HQ will do it, but (a) we are too busy and (b) we represent the suppliers of the API, not the customers. Any volunteeers? Simon

1 0