January 2003 - template-haskell

The ':' operation with patterns ?
by Alain Cremieux 28 Jan '03

28 Jan '03

Hi, I'm trying to code the exemples of "Template Meta-Programming" for Haskell. Since there are differences in the implementation, I'm obliged to understand what I code, which is a good exercise. At present I'm stuck in the mkZip function, because I'm unable to create a pattern which is a list concatenation of 2 patterns. For expressions I can use 'listExp', but what is the equivalent for patterns ? the code : -- call : $(zipN 3) as bs cs zipN :: Int -> Expr zipN n | (n <= 0) = fail "Incorrect arg to 'zipN' - zipN n, n >= 1" | otherwise = [| let zp = $(mkZip n [| zp |]) in zp |] mkZip :: Int -> Expr -> Expr mkZip n name = lam pYs (caseE (tup eYs) [m1, m2]) where pXs, pYs, pXSs :: [Patt] eXs, eYs, eXSs :: [Expr] (pXs, eXs) = genPE "x" n -- x1, x2,... (pYs, eYs) = genPE "y" n -- y1, y2,... (pXSs, eXSs) = genPE "xs" n -- xs1, xs2,... --pcons x xs = [p| $x : $xs |] pcons :: Patt -> Patt -> Patt pcons x xs = ptup (x : [xs]) -- NOT correct, gives (x, xs) instead of x : xs b :: Expr -- ((x1, x2,...) : (zp xs1 xs2 ...)) b = listExp [tup eXs, apps (name : eXSs)] m1 :: Mtch -- ((x1:xs1), (x2:xs2),...) -> ((x1, x2,...) : (zp xs1 xs2 ...)) m1 = alt (ptup (zipWith pcons pXs pXSs)) b m2 :: Mtch -- (_, _,...) -> [] m2 = alt (ptup (replicate n pwild)) (listExp []) -- alt = (a1, a2, ..., an) -> ai -- the match part of a case clause (just an example) alt :: Patt -> Expr -> Mtch alt p e = do x <- e return (Mat p (Normal x) []) Thanks, Alain

2 1

Incomplete implementation of declaration reification
by Sean Seefried 23 Jan '03

23 Jan '03

You are probably already aware of this but a declaration such as d1 = [d| id :: a -> a id x = x |] cannot be reified as of yet because the function "trans" in ghc/compiler/hsSyn/Convert.lhs does not contain a clause for the type constructor TForall. The relevent error message is: ghc-5.05: panic! (the `impossible' happened, GHC version 5.05): hsSyn/Convert.lhs:284: Non-exhaustive patterns in function trans Sean

1 0

RE: [Template-haskell] A subtle bug with GHC
by Simon Peyton-Jones 22 Jan '03

22 Jan '03

Excellent point. I know exactly what is happening and am fixing it as we speak S | -----Original Message----- | From: Sean Seefried [mailto:seefried@itee.uq.edu.au] | Sent: 20 January 2003 05:28 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] A subtle bug with GHC | | I've noticed a subtle bug with TH. It took me some time to realise what | was happening. First I will present my source files. | | --- [Splices.hs] ---- | module Splices where | | import Char | import Language.Haskell.THSyntax | | debug f = [| do { putStrLn (show ( $(f) + 3)) ; | putStrLn "Hello World!" } |] | | ---------------------------- | --- [ Main.hs] --------- | | module Main where | | import Language.Haskell.THSyntax | import Splices | | main = $(debug [| (1::Integer) |]) | ----------------------------- | | When I compile this from scratch using the command line: | | prompt> ghc --make -fglasgow-exts -package haskell-src -package | haskell98 Main.hs -o test | | we get | | prompt> | Chasing modules from: Main.hs | Compiling 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. | Linking ... | | And the program works as expected. But I noticed that when I made a | small change to Main.hs and recompiled the following would occur: | | 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. | | No instance for (Monad IO) | arising from a do statement at <compiler-generated-code> | In a right-hand side of function `main': | $[splice](debug [| (1 :: Integer) |]) | In the definition of `main': | main = $[splice](debug [| (1 :: Integer) |]) | make: *** [all] Error 1 | | | I can repeat this error at will. As long as Splices.hi and Splices.o | are in existence the above error will occur when trying to recompile | Main.hs. | | I was using ghc-5.05.20030118 | | Sean Seefried | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

RE: [Template-haskell] Template Haskell and Hydra
by John O'Donnell 21 Jan '03

21 Jan '03

Tim and Simon, Thanks for the suggestions. I'll go ahead and try this, and let you know how it works out. John

1 0

RE: [Template-haskell] Template Haskell and Hydra
by Simon Peyton-Jones 21 Jan '03

21 Jan '03

| Thanks for the suggestion - that certainly would be fine as | an interim solution, and I'll give it a try as soon as | the declaration brackets are implemented. My impression is | that they aren't there yet? No, declaration brackets are there already! Remember, though, that you can only splice in a separate module. So in: | > d1 = [d| f1 :: Clocked a => a -> a -> (a,a) | > f1 a b = (x, z) | > where (x,y) = (f2 a y, f3 b x) | > z = f4 a (f5 x y) z | > |] | > | > f1 = splice d1 This isn't quite right. For a start, the splice should look like $d1 (No "f1 ="; that's in the code already.) Secondly the splice has to be in a separate module (sorry). So define d1 in one module, and splice it in another. (Reason: you are running code. This is an impl restriction; could be lifted with more work.) let us know how you get on. Simon

1 0

Template Haskell and Hydra
by John O'Donnell 20 Jan '03

20 Jan '03

Hi Simon, I have a possible application for template Haskell, but am not sure whether it will work out. The application is Hydra, where function definitions need to be transformed. I can see three approaches: 1. Do the transformation by hand. This is acceptable only as an interim approach, although I've been doing it for quite some time. 2. Use Template Haskell. Actually, my application is typical of the kind of thing that Scheme macros are good for. 3. Write a parser for Hydra (which would be a subset of Haskell), turn it into a syntax tree, and do the transformation there. I recently started working on (3), which is flexible but a pretty heavyweight approach. But if (2) were flexible enough, it would be preferable. Here's an example of the kind of transformation I'd like to perform: Given this original program... f1 :: Clocked a => a -> a -> (a,a) f1 a b = (x, z) where (x,y) = (f2 a y, f3 b x) z = f4 a (f5 x y) z transform it to... f1 :: (Clocked a, Structural a) => a -> a -> (a,a) f1 a b = (x', z') where -- These equations are similar to the original ones: (x,y) = (f2 a' y', f3 b' x') z = f4 a' (f5 x' y') z' -- These new equations specify the names and structure -- of the definition: p = glob1 "f1" [sgl a', sgl b'] (pair (sgl x') (sgl z')) [x',y',z'] a' = glob2 p a "a" (Input 1 Sgl) b' = glob2 p b "b" (Input 2 Sgl) x' = glob2 p x "x" (Equation 1 (Pair 1 Sgl)) y' = glob2 p y "y" (Equation 1 (Pair 2 Sgl)) z' = glob2 p z "z" (Equation 2 Sgl) The details of the transformation aren't too important, and are likely to change, but the salient points are: -- The transformed definition follows the structure of the original one --- the equations in the original appear in similar form in the final version --- but there are some extra definitions. -- The names used in the original definition appear as literal strings in the transformed one. This is analogous to what's often needed for debugging, although Hydra uses this information for more than just debugging. This is similar to what Sean Seefried requested in an earlier email, where he wanted to be able to show the name of a function defined at the top level. -- The structure of the original definition (e.g. which equation within the `where' clause contains the definition of a name) is made explicit in the transformed version. -- Some globally defined functions (glob1 etc) are introduced in the transformation; these are imported from another module. -- Functions f2, ... used within the original definition of f1 are used also in the transformed version of f1. These need to have definitions with types compatible with their use in the transformed f1, but it is not the responsibility of the transformation to ensure this. Apparently Template Haskell can't implement such a transformation now, since it can't reify top level functions. It might be possible to implement the transformation partially, with enough $ and [|...|] embedded in the original definition, but I suspect that this would introduce too much syntactic noise in the definition, and it would be better just to use the explicit heavyweight parser/transformer. To support this kind of transformation, it would be necessary to allow top level definitions to be reified, but I think it might be best to go farther, and allow an entire module to be reified. Simon P J made the following points about problems with top level function reification; here are some comments in the context of my application... > a) Inconvenience (it's a little tiresome to implement) I can believe this! It probably comes down to a tradeoff between difficulty of implementation and usefulness. Hydra is a potential application which really needs a top-level reification; the only alternative I can see is the separate parser and transformer. > b) It would be particularly difficult to get the definition of a > function defined in another module (because we'd have to read that > entire module too). This is not true of data type declarations, which > travel in interface files, so there is no ugly cross-module issue to > worry about. Right. And that would be needed for some purposes, such as optimisations based on global transformations across functions. However, for Hydra, it isn't necessary to get the definition of any other function; all that matters is its type. And the transformation doesn't even need to know the type of any other function; the typechecking of the final source program will be sufficient. > c) I'm not quite clear what you'd expect to get. If we have > > f = ...f... > > it's easy enough. If you have mutual recursion > > f = ...g... > g = ...f... > > do you get just f's definition, or g's too? If it's a pattern binding > > (f,g) = ... > > you can't avoid getting both. > > And even if it's a simple, non-recursive defn > > f = ....g.... > > (where g is defined earlier), I wonder whether there should be some way > to get at g's definition too. Cases like > f = ...g... > g = ...f... are typical in Hydra. However, to transform the definition of f, we don't need the definition of g. Any application of the form (g a b c) appearing in f will just be transformed into (g a' b' c'). Naturally, a global optimisation might require the definitions of all the functions that are used, but I don't need such things (yet). I think the point here is that any transformation of f that requires the definition of g should require g to be defined in the same module as f. If it were possible to reify an entire module, then it would be possible to do some very general inter-function transformations, but these wouldn't be able to cross module boundaries for the reasons Simon gives. I think that is a reasonable restriction, and this kind of flexibility might be worthwhile. For my own current purposes, all that's really needed is the ability to reify every top level definition. It seems to me that if the ghc team is willing to implement that, it would likely be worth while going all the way for complete module reification. Where would you introduce a reify application for a complete module? Instead of writing Template Haskell notations in the module, what about the following idea: introduce a ghc/ghci switch, so that ghc -... -ftransform-module-with Foo M.hs would run Foo.Main on the reification of the complete module M, and compile the result. This would make it possible to compile M without the switch (so you get the original definitions in M.hs), as well as with the switch (so you get the transformed definitions). I'm not sure how best to distinguish between the two versions of the definitions in M; perhaps as M.f1 vs. M.Foo.f1, or with "import M" vs. "import M.Foo", or something like that. There still could be some advantages to using a separate parser and transformer, rather than Template Haskell. One thing I'd like to experiment with is a slightly enhanced typechecking algorithm, for example. But it might even be possible to do that using reified types obtained from Template Haskell. If that were workable, it would be simpler and more elegant than doing a complete typechecker from scratch. But these typing issues are not the main story for me right now, they are for the future. Would it be feasible to do something like this? Do you forsee any tricky problems with it? Would it be worthwhile? (to anybody besides me :-) Cheers, John O'Donnell

2 2

RE: [Template-haskell] Ramblings on TH names
by Simon Peyton-Jones 20 Jan '03

20 Jan '03

| I'm beginning to work with TH. I'm sincerely finding the whole thing | extraordinary, using (nearly) plain Haskell to write Haskell macros. I | think this idea will have great echoes on the programming community : | Haskell was already the best language, so now it will be a model for | everyone (I am dreaming). If you start to use TH for something real, I'd be fascinated to know some details. Future developments will be driven largely by applications, so pls let us know how it goes. | There is a drawback in the current implementation though : I think the | names of the data and functions are terrible ! I don't think we have any big investment in the particular names. We tried to be consistent in their length, to indicate which 'family' they come from, but I'm not sure that really comes off. In short, concrete, worked out suggestions for how to improve the naming would be very welcome. Simon

1 0

A subtle bug with GHC
by Sean Seefried 20 Jan '03

20 Jan '03

I've noticed a subtle bug with TH. It took me some time to realise what was happening. First I will present my source files. --- [Splices.hs] ---- module Splices where import Char import Language.Haskell.THSyntax debug f = [| do { putStrLn (show ( $(f) + 3)) ; putStrLn "Hello World!" } |] ---------------------------- --- [ Main.hs] --------- module Main where import Language.Haskell.THSyntax import Splices main = $(debug [| (1::Integer) |]) ----------------------------- When I compile this from scratch using the command line: prompt> ghc --make -fglasgow-exts -package haskell-src -package haskell98 Main.hs -o test we get prompt> Chasing modules from: Main.hs Compiling 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. Linking ... And the program works as expected. But I noticed that when I made a small change to Main.hs and recompiled the following would occur: 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. No instance for (Monad IO) arising from a do statement at <compiler-generated-code> In a right-hand side of function `main': $[splice](debug [| (1 :: Integer) |]) In the definition of `main': main = $[splice](debug [| (1 :: Integer) |]) make: *** [all] Error 1 I can repeat this error at will. As long as Splices.hi and Splices.o are in existence the above error will occur when trying to recompile Main.hs. I was using ghc-5.05.20030118 Sean Seefried

1 0

Ramblings on TH names
by Alain Cremieux 19 Jan '03

19 Jan '03

Hi, I'm beginning to work with TH. I'm sincerely finding the whole thing extraordinary, using (nearly) plain Haskell to write Haskell macros. I think this idea will have great echoes on the programming community : Haskell was already the best language, so now it will be a model for everyone (I am dreaming). There is a drawback in the current implementation though : I think the names of the data and functions are terrible ! First they are way too short. Describing a combined concept in 4 letters is OK for people who invented them, not for common users. And I don't see any logic in the spelling : Mat, Match and Mtch, no way to remember that ! But one is a constructor, the same one is a type, one is a data type, and the last one is a monad type. There is also Exp and Expr, dotdotC which should may be spelled dotDotC,Con Constr Cons, and so on May be we can now have the opportunity to find a clear rule, involving prefixing or suffixing and a sufficient number of letters, before everyone use it and it is impossible to change it. Maybe functions and data in TH should have some marking symbol (everything begins with th or TH) so it is easier to see what is executed at compilation and what is executed at run-time (I know that TH functions are ordinary functions though). Well, I've said it. Anyway I still think TH is a big step in a language that was already far ahead, and its designers deserve standing ovations. Alain

1 0

RE: Another question regarding Template Haskell
by Simon Peyton-Jones 13 Jan '03

13 Jan '03

| Would it be possible to write a function "showFun" such that one could | write a program | | f x y = x +y -- say | | main = putStrLn (show $(showFun f)) | | and the result of this program would be | | "f" | | I don't think it's possible at the moment because one can't reify | expressions. That's right. In an earlier posting I explained why I have been slow about implementing expression reification (enclosed). Feedback on exactly what expression reification should do would help to un-glue me. Simon ========================================== | Why is it that one can't reify top level function declarations? At the | moment it only seems that we can reify type declarations. No immediate | reason for this seems to spring to mind, but there may be one. [I'm interested to know something about your application, incidentally.] Several reasons conspire. a) Inconvenience (it's a little tiresome to implement) b) It would be particularly difficult to get the definition of a function defined in another module (because we'd have to read that entire module too). This is not true of data type declarations, which travel in interface files, so there is no ugly cross-module issue to worry about. c) I'm not quite clear what you'd expect to get. If we have f = ...f... it's easy enough. If you have mutual recursion f = ...g... g = ...f... do you get just f's definition, or g's too? If it's a pattern binding (f,g) = ... you can't avoid getting both. And even if it's a simple, non-recursive defn f = ....g.... (where g is defined earlier), I wonder whether there should be some way to get at g's definition too.

1 0