July 2003 - template-haskell

RE: [Template-haskell] Profiling with Template Haskell
by Simon Peyton-Jones 07 Aug '03

07 Aug '03

| Now I know that profiling splicing doesn't make too much sense. That | is not what I wish to do though. I wish to profile the final | executable. Hmm, yes good point. GHC compiles different binaries for profiled and non-profiled execution. Splice code that runs at compile time should presumably be non-profiled (though I'm sure someone will want to profile it too). So TH should link non-profiled libraries at compile time, but it's not clever enough to realise this. I'll put this on my list of things to fix. I'm in the middle of a heart transplant on GHC at the moment, aimed at making a better substrate for TH, so I may not fix this very quickly unless it's important to you. It will mean that you'll have to compile your own program modules both profiled and non-profiled -- the former for run-time and the latter for compile time -- unless you keep compile-time code and run-time code in separate modules. That's annoying but I don't see an easy alternative. Simon

2 1

RE: [Template-haskell] reifyDecl problem
by Sean Seefried 29 Jul '03

29 Jul '03

On Sun, 27 Jul 2003, Tim Sheard wrote: > At 08:22 AM 7/23/2003 +1000, you wrote: > >So correct me if I am wrong. Quasi-quoatation is not reification because > >quasi-quoted code is not a data structure, it is simply another form of > >expression. > > Quasi quoted code is sort of special. It is both a data structure > and a delayed expression. When I talk of reification, I mean a way > to turn a value into a quoted piece of code. > > reify (pred . succ) ---> [| \ x -> x |] > > This is not possible in MetaML. Can one do case analysis on the structure of quasi-quoted code however? Sean

1 0

RE: [Template-haskell] reifyDecl problem
by Simon Peyton-Jones 22 Jul '03

22 Jul '03

| > But Section 8.1 of "Template Meta-programming for Haskell" says: | > | > "In a similar way, reifyDecl f, gives a data structure | > that represens the value declaration for f;..." | > | > and later "... useful to restrict the use of reifyDecl to type | > constructors, classes, or variables (e.g. functions) declared at the | > top level..." | > | > From that I made a conclusion that it is possible to reify function | > declarations (the most interesting ability of TH to me comparing with | > C++, for instance). And I still hope :) that it is possible and the | > error message above is just due to mere bug. | | This you definitely can't do and oh, how I wish you could. The closest | you can get is to define a function as reified code and then splice it. | Example: | | d_fun = [d| fun = <function body> |] You can certainly consider it a missing feature, if not exactly a bug (though the error message is horrible). I think you'll always be restricted to functions defined in the same module. For example import Prelude foo = $(do_it (reifyDecl map)) won't work, because 'map' isn't defined in this module. To make this work, I'd need to store the original source code for every function in each module's interface file, just in case someone later imported and reified it. But it seems a bit unpleasant for module boundaries to be significant in this way. I'm not sure what to do about this. I'd be interested to know whether the same-module restriction would defeat the purposes for the "oh, how I wish I could" applications. simon Simon

2 1

reifyDecl problem
by Dmitry Malenko 22 Jul '03

22 Jul '03

Hi, All! In test code given below trying to reifyDecl function or constant declaration couse GHC to panic. Both CVS HEAD and 6.0. Am I mising something in reification of function declarations or is this reakky a bug in GHC? [dima@farside tmp]$ ghc --make -fglasgow-exts Main.hs Chasing modules from: Main.hs Compiling Main ( ./Main.hs, ./Main.o ) ghc-6.1: panic! (the `impossible' happened, GHC version 6.1): dsReify reifyDecl Main.l {- v rcA -} Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. [dima@farside tmp]$ ghc-6.0 --make -fglasgow-exts Main.hs Chasing modules from: Main.hs Compiling Main ( Main.hs, ./Main.o ) ghc-6.0: panic! (the `impossible' happened, GHC version 6.0): dsReify reifyDecl Main.l {- v rcz -} Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. \begin{code} import IO import Language.Haskell.THSyntax data T = A String | B l = A "kuku" f x = x k = reifyDecl l main :: IO () main = do x <- unQ k putStrLn (show x) \end{code} -- Best regards, Dmitry Malenko +----------------------------------------------------+ Registered Linux user #258004 ALT Linux Team http://www.altlinux.ru +----------------------------------------------------+ Marriage, n.: The evil aye.

2 3

Profiling with Template Haskell (continued)
by Sean Seefried 19 Jul '03

19 Jul '03

Hi all, I've been thinking about the profiling problem a little bit during the night and I've come up with some ideas and queries. I wish to clarify the following. There are three forms of a standard library aren't there? a) static library without profiling (e.g. libHSbase.a) b) static library with profiling (e.g. libHSbase_p.a) c) an equivalent object file for including the library in GHCi and during splicing in Template Haskell. (e.g. HSbase.o) When a module that contains splicing is compiled it seems to me that the third type of library is linked in (if it exists), followed by a an attempt to link in in a shared library. (e.g. libHSbase.so). Say we have a file Main.hs which includes splices from Splices.hs. Say we are just about to compile Main.hs and Splices.o exists. Then the symbols from Splices.o will be linked in during the splicing process right? But this is going to fail if Splices.hs was compiled with profiling on. And why is this? Splices.o will contain the undefined symbol '_CCS' if it is compiled with '-prof'. So when we link it in during the splicing process we are going to need this symbol to be defined somewhere. Well, I've had a brief look at the standard libraries that come with GHC and none of the .o forms of the libraries (type c above) has this symbol defined in them, but the symbol _is_ defined in all the static libraries that we built with profiling on (type b above). It seems to me that we require two types of .o library - one in which profiling was included and one it which it was not. Otherwise how can we compile programs using Template Haskell using the '-prof' option? Sean

1 0

Profiling with Template Haskell
by Sean Seefried 18 Jul '03

18 Jul '03

Hi all, I'd just like to find out what your experiences with profiling TH programs are? I'm not sure GHC-6.0 accomodate profiling when Template Haskell is involved. A really simple example that doesn't work is: ghc -prof -fglasgow-exts -make Main.hs applied to ----------------- {- Splices.hs -} module Splices where import Language.Haskell.THSyntax d_fun = [d| fun = putStrLn "I am a function" |] ----------------- {- Main.hs -} module Main where import Splices $(d_fun) main = fun ---------------- The output is : Chasing modules from: Main.hs Skipping Splices ( Splices.hs, ./Splices.o ) Compiling Main ( Main.hs, ./Main.o ) Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package haskell-src ... linking ... done. ./Splices.o: unknown symbol `_CCCS' I'll bet that _CCCS is a cost center symbol that is (correctly) added to Splices.o. This symbol is present in many of the standard libraries (compiled with profiling support enabled. e.g. libHSbase_p.a contains the symbol) Now I know that profiling splicing doesn't make too much sense. That is not what I wish to do though. I wish to profile the final executable. I'm aware that when splicing much of the functionality of GHCi is used. Consider the three lines from the input above: Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package haskell-src ... linking ... done. I think these are spat out from Linker.lhs. (It resides in the ghc/compiler/ghci directory of the GHC source.) Of course, at this point in compilation "_CCCS" is undefined. Is there anyway that we can get the linker to ignore profiling symbols during this phase of the compilation? How are we profile programs that use Template Haskell otherwise? Sean

1 0

re: newbie question
by Isaac Jones 09 Jul '03

09 Jul '03

> [Isaac, you need to join the TH list so you can post to it without > me having to intervene.] Done > Your original makeSum looked better. OK, thats what I was hoping. > Solution: use the "smart constructors" from the paper. More like > this: > genSummers n = fun ("makeSum" ++ (show i)) [clause [] (normal > (makeSum i)) [] ] Thanks, for some reason I was blind to the combination of using the "smart constructors" in together with sequenceQ. I thought I had tried every combination to make the types work out. Here's my solution below. peace, isaac \begin{code} -- |Given a size, n and n expressions, sum them up, so: -- > $(makeSum 4) 1 2 3 10 -- => 16 -- > $(makeSum 4) 1.0 2.2 3.4 10.1 -- => 16.7 makeSum :: Int -> ExpQ makeSum n = lam aPats (sumExps aVars) where -- create the symbols we'll need: aPats ::[Pat] aVars ::[ExpQ] (aPats,aVars) = genPE "num" n sumExps :: [ExpQ] -> ExpQ sumExps (h:t) = [| $h + $(sumExps t) |] sumExps [] = [| 0 |] -- |Bring functions named makeSumX into scope where X is in [1..n] genSummers :: Int -> Q [Dec] genSummers n = sequenceQ [fun ("makeSum" ++ (show i)) [clause [] (normal (makeSum i)) [] ] | i <- [1..n] ] -- Then in a different file, I can say -- $(genSummers 10) -- to bring makeSum1, makeSum2, etc into scope \end{code}

1 0

RE: [Template-haskell] newbie question
by Simon Peyton-Jones 09 Jul '03

09 Jul '03

[Isaac, you need to join the TH list so you can post to it without me having to intervene.] | > genSummers n = returnQ [Fun ("makeSum" ++ (show i)) [Clause [] (Normal $(makeSum i)) [] ] | i | <- [1..n] ] | | But actually, I run into a stage restriction. You don't want a splice there! But if you remove it, (makeSum i) returns an ExpQ, whereas Normal wants an Exp. | > makeSumE :: Int -> Exp If you want to generate fresh (rather than fixed) variable names in makeSum, it definitely needs to return an ExpQ, not an Exp. An Exp is simply a data structure. An ExpQ (= Q Exp) is a monadic computation which can generate fresh names. Usually better. Your original makeSum looked better. | > genSummers n = returnQ [Fun ("makeSum" ++ (show i)) [Clause [] (Normal (makeSumE i)) [] ] | i | <- [1..n] ] if makeSum returns an ExpQ, you can't do this for the reason above. Solution: use the "smart constructors" from the paper. More like this: genSummers n = fun ("makeSum" ++ (show i)) [clause [] (normal (makeSum i)) [] ] Simon

1 0

newbie question
by Isaac Jones 08 Jul '03

08 Jul '03

Greetings, I'm new to Template Haskell and am trying to work out some examples. I successfully used this function (makeSum n) to generate a function that takes n arguments. \begin{code} -- |Given a size, n and n expressions, sum them up, so: -- > $(makeSum 4) 1 2 3 10 -- => 16 -- > $(makeSum 4) 1.0 2.2 3.4 10.1 -- => 16.7 makeSum :: Int -> ExpQ makeSum n = lam aPats (sumExps aVars) where -- create the symbols we'll need: aPats ::[Pat] aVars ::[ExpQ] (aPats,aVars) = genPE "num" n sumExps :: [ExpQ] -> ExpQ sumExps (h:t) = [| $h + $(sumExps t) |] sumExps [] = [| 0 |] \end{code} Now I would like to bring a bunch of versions of this function into scope, something like > $(genSummers 10) where genSummers :: Int -> Q [Dec] and brings into scope: makeSum0 :: Int ... makeSum2 :: Int -> Int -> Int ... makeSum10 :: ... So this seems to make sense: > genSummers n = returnQ [Fun ("makeSum" ++ (show i)) [Clause [] (Normal $(makeSum i)) [] ] | i <- [1..n] ] But actually, I run into a stage restriction. Now I can create a function: > makeSumE :: Int -> Exp and say: > genSummers n = returnQ [Fun ("makeSum" ++ (show i)) [Clause [] (Normal (makeSumE i)) [] ] | i <- [1..n] ] But how to define makeSumE? I try this: \begin{code} makeSumE :: Int -> Exp makeSumE n = Lam aPats (sumExps aVars) where -- create the symbols we'll need: aPats ::[Pat] aVars ::[Exp] (aPats,aVars) = genPE' "num" n sumExps :: [Exp] -> Exp sumExps (h:t) = [| $h + $(sumExps t) |] --oops, can't do that sumExps [] = Lit $ Integer 0 \end{code} But alas, the commented line is not the right type. So how do I write genSummers? peace, isaac ps. I implemented the printf and sel examples from the paper with the real stuff from the GHC6 library, and that code can be found on the wiki: http://www.haskell.org/hawiki/TemplateHaskell Maybe when I come up with a handful of nice examples I can add them to the haddock for the Language.Haskell.THSyntax

1 0

RE: [Template-haskell] reifyType function
by Simon Peyton-Jones 07 Jul '03

07 Jul '03

I think you'll find that class Typeable, defined in Data.Dynamic, is pretty much exactly the class you describe. It's indeed a good thing. Simon | -----Original Message----- | From: template-haskell-admin(a)haskell.org [mailto:template-haskell-admin@haskell.org] On Behalf Of | Andre Pang | Sent: 07 July 2003 09:55 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] reifyType function | | Hi all, | | Sean Seefried and I managed to implement a reifyType function, which | we're calling rType since there's already that annoying built-in | reifyType identifier ;). It's defined in a ReifyType module which | looks like thus: | | --8<-- | module ReifyType | where | | import Data.Dynamic | import Language.Haskell.THSyntax | | class ReifyType a where | rType :: a -> Typ | | instance (ReifyType a, ReifyType b) => ReifyType (a, b) where | rType (_ :: (t, u)) = Tapp (Tapp (Tcon (Tuple 2)) (rType (undefined | :: t))) | (rType (undefined :: u)) | | instance ReifyType a => ReifyType [a] where | rType (_ :: [t]) = Tapp (Tcon List) (rType (undefined :: t)) | | instance Typeable a => ReifyType a where | rType (_ :: t) = (Tcon (TconName typeAsString)) | where | typeAsString = show $ typeOf (undefined :: t) | | instance (ReifyType a, ReifyType b) => ReifyType (a->b) where | rType (_ :: t -> u) | = (Tapp (rType (undefined :: t)) (rType (undefined :: u))) | --8<-- | | An example of how to use it: | | 18:48 ~/Desktop % ghci -fglasgow-exts -fallow-overlapping-instances | -fallow-undecidable-instances ReifyType.hs | Type.hs) | ... | Loading package base ... linking ... done. | Compiling ReifyType ( ReifyType.hs, interpreted ) | Ok, modules loaded: ReifyType. | *ReifyType> rType Char.toLower | Loading package haskell98 ... linking ... done. | Loading package haskell-src ... linking ... done. | Tapp (Tcon (TconName "Char")) (Tcon (TconName "Char")) | *ReifyType> rType ((+) :: (Int -> Int -> Int)) | Tapp (Tcon (TconName "Int")) (Tapp (Tcon (TconName "Int")) (Tcon | (TconName "Int"))) | *ReifyType> rType "foobar" | Tapp (Tcon List) (Tcon (TconName "Char")) | *ReifyType> | | The major restriction is that you're limited to using it on monomorphic | types (since the typeOf function only works on monomorphic types), but | otherwise, it seems to work remarkably well. | | | -- | % Andre Pang : just.your.average.bounty.hunter | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0