November 2007 - template-haskell

Doctoral and Post-doctoral openings at Rice
by Walid Taha 30 Nov '07

30 Nov '07

The Resource-Aware Programming (RAP) research group at Rice University is seeking qualified doctoral and post-doctoral students. The openings will support work on a wide range of topics, including the Concoqtion programming language, physically safe computing, and device drivers. The full descriptions of these positions can be found at: http://www.resource-aware.org/twiki/bin/view/RAP/OpeningsGraduate and http://www.resource-aware.org/twiki/bin/view/RAP/OpeningsPostdoctoral Funding for these positions is provided by the National Science Foundation (NSF) and by industrial partners including Intel, LogicBlox, and Schlumberger. Walid Taha, http://www.cs.rice.edu/~taha Department of Computer Science Rice University Houston, TX 77025

1 0

TupleT type constructor
by Alfonso Acosta 05 Nov '07

05 Nov '07

Hi, I'm a bit confused about TupleT . Is is supposed to be only used when synthesizing types? (i.e. reify will never output such a type)? ~/ghc/compiler/stage2$ ./ghc-inplace --interactive -fth GHCi, version 6.9.20071025: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m +Language.Haskell.TH Prelude Language.Haskell.TH> let l = (1,2) Prelude Language.Haskell.TH> $( do {VarI _ t _ _ <- reify (mkName "l"); runIO $ putStrLn (pprint t); [| 1 |]}) Loading package array-0.1 ... linking ... done. Loading package packedstring-0.1 ... linking ... done. Loading package containers-0.1 ... linking ... done. Loading package pretty-1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Data.Tuple.(,) GHC.Num.Integer GHC.Num.Integer Data.Tuple.(,) GHC.Num.Integer GHC.Num.Integer Data.Tuple.(,) GHC.Num.Integer GHC.Num.Integer Data.Tuple.(,) GHC.Num.Integer GHC.Num.Integer 1 (The four outputs are a known TH bug) >From the definition of "Type" I would have expected to get (TupleT 2 `AppT` ConT "GHC.Num.Integer") `AppT` (ConT "GHC.Num.Integer") Should this be considered a bug or a feature? IMHO it's quite ugly to have two valid representations for the same type in the same AST structure. Best Regards, Fons

3 5

Extending the reification information of a class with its known instances
by Alfonso Acosta 05 Nov '07

05 Nov '07

Hi, I don't know whether this can be considered a generally desired feature, that's why I didn't create the ticket directly. I have to code a TH processing function, which, due to the untyped nature of the TH's AST, as it seems, would only be able to guarantee generating valid code if instance information of a class could be obtained. In my concrete case I have to, among other things, keep the AST of a function (for later processing by my embedded compiler) and it's value in Dynamic form (for later simulation of my embedded language). -- phantom parameter to guarantee type correctness newtype MyFun a = MyFun MyFunPrim data MyFunPrim = MyFun Name [Clause] Dynamic My TH constructor function has the type mkMyFun :: Q [Dec] -> ExpQ and a (naive) concrete example of use could be myFun1 :: MyFun (Bool -> Bool) myFun1 = $(mkMyFun [d| and :: Bool -> Bool and a b = a && b |]) The problem comes when generating the Dynamic value. There is no way to guarantee that the function. The only solutions I can think of to solve my problem are: a) The hard way: providing a catching mechanism badly generated code. b) The cleaner way: Providing a mechanism to check whether the function passed to mkMyFun is Typeable. something like isClassInstance :: Name -- ^ Class name -> Type -- ^ Type to check -> Bool (and maybe c) Hope for a new TH with a typed AST which could let me expess type constraints in declarations and expressions.) Right now, I can only expect the user to be nice and only supply Typeable functions. Cheers, Fons

2 2

Obtaining the declaration of a variable name.
by Alfonso Acosta 05 Nov '07

05 Nov '07

Hi, The reification information of a variable is declared as: VarI Name Type (Maybe Dec) Fixity When I began using TH, I thought it was great to be able to retreive the declaration of a variable out of its name (it would have turned out to be pretty useful). However, after testing that reify returned Nothing all the time, I figured out I sadly couldn't count on that. That feature seems to be handy for my compiler again so I tried to guess what was wrong. According to Language.TH.Syntax: -- Nothing for lambda-bound variables, and -- for anything else TH can't figure out -- E.g. [| let x = 1 in $(do { d <- reify 'x; .. }) |] However, the typechecker (TcSplice module) always returns Nothing. So I guess it's simply not implemented. Am I missing something or should I add a feature request ticket? Thanks, Fons

3 2

Re: [Template-haskell] Lift instances of the AST-related types
by Alfonso Acosta 04 Nov '07

04 Nov '07

This recent haskell-cafe thread[1] provides a way to implicity give support for automatic derivation of Lift in GHC. Since Data can be derived automatically and there's a way to lift any "Data a => a" it's like having automatic derivation for lift. It's not a substitute of Ian's package (the instace Data a => Lift a is illegal), but it complements it. What do you think about including a function like "liftData :: Data a => a -> ExpQ" in the library? On 11/2/07, Alfonso Acosta <alfonso.acosta(a)gmail.com> wrote: > On 11/2/07, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > > It'd be good to check that the Haddock docs for TH.Lift are in good shape. > > Well, right now they are inexistent but the library is tiny, that > shouldn't be a problem. > > > I'll leave this up to you two to finalise. > > Let's see what Ian thinks > > > (In fact it'd be great if you could improve the Haddock docs for the other TH modules. They are currently laughably bad. And you are clearly an expert!) > > I cannot agree more, when I began to use TH I was forced (and I keep > doing it) to look at the source comments to check what the AST-types > meant. > > I cannot promess anything for the short-term, but I'll try to send a > documentation patch at some point. >

2 2

Lift instances of the AST-related types
by Alfonso Acosta 01 Nov '07

01 Nov '07

Hi, It has been suggested a few types in this list [1,2] that it would be helpful to include a Lift instance of Exp, Type, Dec and friends. Having such instances allow to store the AST in a TH-generated structure for later processing during runtime (something curcial in the embedded compiler I'm currently developing). It would be great that the instances were included in the library itself or if (even better) GHC supported automatic deriving of Lift. Until that happens, I have used a modified version Ian's th-lift[3] to automatically generate the instances. Just in case anyone is interested, I attached the patch of th-lift and the instantiation module. Cheers, Fons [1] http://www.haskell.org/pipermail/template-haskell/2007-February/000593.html [2] http://www.haskell.org/pipermail/template-haskell/2004-June/000289.html [3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/th-lift-0.2

2 2