- template-haskell - Haskell.org

Re: Polymorphism + Quasiquoting + Untyped AST = problems
by Alfonso Acosta 20 Feb '08

20 Feb '08

On Wed, Feb 20, 2008 at 9:12 AM, Geoffrey Mainland <mainland(a)eecs.harvard.edu> wrote: > On Wed, Feb 20, 2008 at 08:22:18AM +0100, Alfonso Acosta wrote: > > Hi, > > > > Let me show you why I reached that conclusion through a simple example. > > I can't help but feel I've missed some context :) Well, I'm probably bad at providing simplified examples ;). The real purpose of using quasiquoters is to help implementing fixed sized vectors (numerically parameterized lists using type-level numerals). See http://www.haskell.org/pipermail/haskell-cafe/2008-February/039801.html for details. > > Using "vector" is simple: > > > > $(vector [1,2,3,4,5]) > > Well, not so simple actually, as you'll get an "ambiguous type variable" > error unless you add a type signature. For instance: > > $(vector [1::Int,2,3,4,5]) True, I forgot to include the signature. However, even if a signature is required, vector can still be used to build vectors of any type, whereas that is not the case when using quasiquoters. > The real problem is that you can't splice in a polymorphic > variable. Witness: > > v = QuasiQuoter (fst . vExp) vPat > > vExp :: Read a => String -> (Q Exp, a) > vExp str = do let xs = (parseLTGT str) :: [a] > sanityCheck xs > ([| MkVec xs |], undefined) > Yes, I know. I thought it would maybe be possible if TH had a typed AST.

1 0

Polymorphism + Quasiquoting + Untyped AST = problems
by Alfonso Acosta 20 Feb '08

20 Feb '08

Hi, Let me show you why I reached that conclusion through a simple example. Imagine that, for some reason, we need to implement a DSL which is required to use vectors. Furthermore, we would like to make transformations/sanity checks at compile time. To keep things simple, the vector is internally represented as a list: newtype Vec a = MkVec [a] -- Note that MkVec would be hidden to the end user. Using Template Haskell, we can easily create a constructor function which fulfils all the requirements. vector :: Lift a => [a] -> QExp vector xs = do sanityCheck xs [| MkVec xs |] where sanityCheck = undefined -- not specified Using "vector" is simple: $(vector [1,2,3,4,5]) OK, fair enough. However, pattern matching is lost and it would be nicer to be able to to build vector literals using a syntax different to lists. For example, using less-than and more-than symbols to enclose the vector elements: <1,2,3,4,5> We would also like to do some pattern matching: <> -- empty vector x <xs> -- head and tail of the vector Using a quasiquoter all the above is is possible. In the case of Int vectors, supposing name our quasiquoter v we could do things like. [$v|<1,2,3,4,5,6>|] head :: Vector Int -> Int f v = case v of [$v|<>|] -> error "empty" [$v|x<xs>|] -> x Looks nice, but we lose polymorphism! It is imposible to make v work with any instance of Read! Here is a possible implementation: -- parse a list enclosed with lower-than and greater-than characters parseLTGT :: Read a => String -> [a] parseLTGT = undefined -- code ommited v = QuasiQuoter vExp vPat -- In the case of Ints it is simple vExp :: String -> Q Exp vExp str = do let xs = (readLTGT str) :: [Int] sanityCheck xs [| MkVec xs |] Unfortunately, we cannot implement vExpr in the general case. Removing the explicit signature of readLTGT would lead to ambiguous-type-variable errors. Maybe things would be different if TH's AST wasn't untyped (i.e. vExpr :: String -> Q (Exp a)) I'm not sure if it is feasible, though. I would love to be proven wrong and read about a workaround/solution. Any suggestions? Cheers, Fons

1 1

mutually recursive modules and template haskell
by Alfonso Acosta 04 Jan '08

04 Jan '08

Hi, I recently reopened an old bug related to TH and mutually recursive modules. http://hackage.haskell.org/trac/ghc/ticket/1012 Sorry to repost about the bug in this list but the is being a major blocker for me. It seems that "ghc --make" could do better when figuring out the build dependencies when mutually recursive modules and TH are used in the same set of modules. Could someone please confirm if I really ran into a bug? A workaround for me would providing an specific compilation order (sorry if this is offtopic). I'm using cabal, I tried using Setup makefile to avoid the bug but it didn't work for me (the makefile approach doesn't seem to regard the modules included in "other-modules"). Any pointer would be welcome. Cheers, Fons

2 2

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

[Bug?] AST representation of type-synonyms with phantom parameters
by Alfonso Acosta 30 Oct '07

30 Oct '07

Hi, There seems to be a bug in the type representation of type synonyms with phantom parameters === Phantom.hs === module Phantom where -- non-phantom type synonym type List a = [a] type PhantomSyn a = Int data PhantomData a = PhantomData Int ================== ~/ghc/ghc/compiler/stage2$ ./ghc-inplace -fth --interactive /tmp/Phantom.hs GHCi, version 6.9.20071025: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Phantom ( /tmp/Phantom.hs, interpreted ) Ok, modules loaded: Phantom. *Phantom> let {syn = undefined :: List a; phanSyn = undefined :: PhantomSyn a; phanData = undefined :: PhantomData a} *Phantom> :m +Language.Haskell.TH *Phantom Language.Haskell.TH> let showType name = do {VarI _ t _ _ <- reify name ; 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. *Phantom Language.Haskell.TH> $(showType (mkName "syn")) forall a_0 . Phantom.List a_0 forall a_0 . Phantom.List a_0 forall a_0 . Phantom.List a_0 forall a_0 . Phantom.List a_0 1 *Phantom Language.Haskell.TH> $(showType (mkName "phanSyn")) Phantom.PhantomSyn GHC.Prim.Any Phantom.PhantomSyn GHC.Prim.Any Phantom.PhantomSyn GHC.Prim.Any Phantom.PhantomSyn GHC.Prim.Any 1 *Phantom Language.Haskell.TH> $(showType (mkName "phanData")) forall a_0 . Phantom.PhantomData a_0 forall a_0 . Phantom.PhantomData a_0 forall a_0 . Phantom.PhantomData a_0 forall a_0 . Phantom.PhantomData a_0 1 The output makes sense for "forall a_0 . Phantom.List a_0" and "forall a_0 . Phantom.PhantomData a_0" but why "Phantom.PhantomSyn GHC.Prim.Any"? (just for information purposes, ghc 6.6 uses "()" instead of "Any") Shouldn't it be "forall a_0 . Phantom.PhantomSyn a_0"? Best Regards, Fons PS: BTW, $(showType 'phanSyn) works fine in ghci6.6 but gives a Stage error in HEAD. That's why I used mkName "phanSyn" Is that another bug? (I couldn't find a related ticket in GHC's trac)

2 3