- template-haskell - Haskell.org

Hygienic macros and lexical-scoping
by Kamil Skalski 25 Feb '04

25 Feb '04

Hello! I'm developer of meta-programming system in a new language Nemerle. As we are coming near to implementation of lexical scoping and alpha-renaming in our system, I would like to share some ideas and ask few questions about Haskell Templates' approach to these problems. As I read in 'Template meta-programming in Haskell', the implementation translates [| \x -> $(f [| x |]) |] to do { x <- gensym "x"; lam [Pvar x] (app f (var x) } (I'm not familiar with Haskell, so I may have mistaken some syntax) My question is: when binding of variables is resolved? Is it during translation of quotation, or maybe during expansion of $(...) where the above code is used? After reading the paper, I'm convinced that it's former case. But let's consider: using x val body = [| do { (var x) <- val; body; (var x).Dispose () } |] // x is of type string [| \y -> do { $(using "x" [| x |]); f y |] wouldn't work, and one would have to use gensym by his own to get expected sematics. In our system we are shifting binding of variables from quotation translation to macro expansion phase, so [| x |] can be "catched" inside 'using' meta-function. Resolving of scoping is done after all executions of macros are done. It involves quite complex algorithm to tag variables with place where they come from - we are adapting Dybvig's algorithm into our system, so we could use most flexible convention introduced by Scheme community. Assuming I'm not wrong by now, I also have question, was the other option considered during design of Template Haskell? As we discussed our design, there was some confusion if macros should introduce new definitions into program. I noticed, that in Haskell it is done by special keyword 'splice', and it's forbidden inside quotations. As we decided to resolve names in late phase, we could introduce definitions in arbitrary place. Some questions arise in that case: Let's consider following macros (in Nemerle syntax, as I'm more used to it) using Foo; /// it introduces functions 'blah' and 'bar' variables macro m() { <[ def bar() { 1 } ]> } macro m'() { <[ m(); blah() + bar() ]> } does m'() generate def bar_43 = 1; Foo.blah() + Foo.bar() or def bar_43 () { 1 }; Foo.blah() + bar_43() lexical scoping should theoretically mean the former case, but if we consider function MacroUseSymbol (x : string) - that generates symbol, which will behave as one introduced in macro use site, then latter case is valid. The same function might be used to implement 'using' macro, I've mentioned: macro using (x : string, val, body) { def x = MacroUseSymbol (x); <[ def $(x : var) = $val; $body; $(x : var).Dispose () ]> } My last question is if this approach was considered and what are opinions about introducing this kind of lexial scoping into languages with explicit quoasi-quotations. I can describe our algorithm if anyone is interested (as it is still under discussions). Kamil Skalski Nemerle developer - http://nemerle.org

1 0

Re: [Template-haskell] On reifing functions and partial evaluation
by Duncan Coutts 18 Feb '04

18 Feb '04

On Tue, 2004-02-17 at 09:05, Alastair Reid wrote: > > First the sensational headline: > > ghc beats gcc by 57% on Ackerman benchmark, improved to 290% using > > Template Haskell. > > Any thoughts on how it would compare with a C++ template-based version of ack? > Off the top of my head, I'd say performance ought to drop back to nearer the > 57% better mark but it'd be (mildly) interesting to confirm this. Ok, so to be fair to C/C++ (!) we should really compare like with like in which case we should compare our template-unrolled version with a C++ template unrolled version. As you thought, the performance drops back, but we still win. :-) 75 sec for g++-3.3.2 -O3 -fomit-frame-pointer 40 sec for genex_ack_4 with ghc -O So the percent improvement that the marketing folk would put in their adds would be 87%. So actually we're winning by a greater margin than before. If you're really keen we can get the time down even further: 88 sec for ack_4 with ghc -O2 -fvia-C -optc-O2 (vs 100sec for ghc -O) 32 sec for genex_ack_4 with ghc -O2 -fvia-C -optc-O2 (vs 40sec for ghc -O) Duncan Here's the C++ code: template<int m> class foo { public: static int ack(int n) { if (n==0) return foo<m-1>::ack(1); else return foo<m-1>::ack(ack(n-1)); } }; template<> class foo<0> { public: static int ack(int n) { return n+1; } }; int main (int argc, char *argv[]) { int n = ((argc == 2) ? atoi(argv[1]) : 1); printf("ack 4 %d = %d\n", n, foo<4>::ack(n)); return 0; }

1 0

On reifing functions and partial evaluation
by Duncan Coutts 17 Feb '04

17 Feb '04

All, So I'd like to persuade people of the desirability of being able to reify values/functions. :-) I've now got two ways of potentially doing partial evaluation using Template Haskell, they correspond to two different types for our specialisation function mix. To describe the types, I'm going to pretend that TH is typed. Just erase the phantom type to get real TH (ie Exp a --> ExpQ). mix1 :: Exp (a -> b) -> Exp a -> Exp b eg mix1 [| isJust |] [| Nothing |] This is where we do abstract interpretation of the function on its static argument. Unless the function is a textually a lambda abstraction we can't look at its definition to to the interpretation. The other way that might work has this type: mix2 :: Exp (a -> b) -> a -> Exp b eg mix2 [| isJust |] Nothing Here, the static argument is a value rather than a syntax tree representing a value. It would be desirable to have mix with this type because it avoids the heavy double encoding that we get with mix1 when we apply it to itself. With mix1 we would do cogen = $( mix1 [| mix1 |] [|[| mix1 |]|] ) where as with mix2 we can do cogen = $( mix2 [| mix2 |] [| mix2 |] ) To implement mix with this type, what we do is construct the generating extension of the function we are specialising, apply it to its static argument and splice in the resulting code. For example for isJust, we need to do the following transformation: isJust = \m -> case m of Nothing -> False Just _ -> True --> genex-isJust = \m -> case m of Nothing -> [| False |] Just _ -> [| True |] Now, genex-isJust Nothing = ConE GHC.Base.False (ignoring the Q monad) We could define genex simply as genex f = (\e -> [| e |]) . f But then it would only work for liftable values - ie not functions. Of course with partial evaluation it is functions that are particularly interesting. We typically specialise functions of several arguments on just one or two static arguments - the remaining arguments are accepted at runtime. So, instead of just composing with wrap = (\e -> [| e |]) :: a -> Exp a we'll need genex :: Exp (a -> b) -> Exp (a -> Exp b) and it will have to inspect the definitions of functions/values. Another example: foo s d = case s of Nothing -> False Just _ -> case d of Nothing -> False Just _ -> True --> genex-foo s d = case s of Nothing -> [| False |] Just _ -> [| case d of Nothing -> False Just _ -> True |] The bits in the quasi-quote brackets [| |] are the fragments of the computation that will be deferred to runtime because they depend on an argument to the function that is not known (static) at compile time. We can also get nested $() and [| |] if there are static subexpressions inside a dynamic expression. bar s d = case d of Nothing -> False Just _ -> case d of Nothing -> False Just _ -> True --> genex-bar s d = [| case d of Nothing -> False Just _ -> $( case s of Nothing -> [| False |] Just _ -> [| True |] ) |] This is an example where Ian's idea of adding QQuot and Splice as Exp constructors would make things easier, but it's not essential so long as encodings are possible. On a related issue, I recall Simon PJ wondered about the best way of reifying values in patterns, like: let (a,b) = e reify "a" = ??? What about just applying the appropriate projection reify "a" = [| (\(x,_)->x) e |] I guess there's a danger of people duplicating computations by carelessly manipulating such expressions. ie inadvertently doing the following transformation: let (a,b) = e --> let a = fst e b = snd e Duncan

2 1

[Template-haskell] Second CFP: GPCE'04 -- Generative Programming and Component Engineering
by Eelco Visser 12 Feb '04

12 Feb '04

[Papers about Template Haskell would fit very well in this conference.] SECOND CALL FOR PAPERS ---------------------------------------------------------------------- Third International Conference on Generative Programming and Component Engineering (GPCE'04) Vancouver, October 24-28, 2004 co-located with OOPSLA 2004 and ISMM 2004 http://gpce04.gpce.org ---------------------------------------------------------------------- ------------------------------------ Important Dates ------------------------------------ * Pre-submission: March 12, 2004 * Submission: March 19, 2004 ------------------------------------ Scope ------------------------------------ Generative and component approaches have the potential to revolutionize software development in a similar way as automation and components revolutionized manufacturing. Generative Programming (developing programs that synthesize other programs), Component Engineering (raising the level of modularization and analysis in application design), and Domain-Specific Languages (elevating program specifications to compact domain-specific notations that are easier to write and maintain) are key technologies for automating program development. GPCE arose as a joint conference, merging the prior conference on Generative and Component-Based Software Engineering (GCSE) and the Workshop on Semantics, Applications, and Implementation of Program Generation (SAIG). The goal of GPCE is to provide a meeting place for researchers and practitioners interested in cutting edge approaches to software development. We aim to foster further cross-fertilization between the software engineering research community on the one hand, and the programming languages community on the other, in addition to supporting the original research goals of both the GCSE and the SAIG communities. We seek papers both in software engineering and in programming languages, and especially those that bridge the gap and are accessible to both communities at the same time. ------------------------------------ Topics of Interest ------------------------------------ The conference solicits submissions related (but not limited) to: * Generative programming o Reuse, meta-programming, partial evaluation, multi-stage and multi-level languages, step-wise refinement o Semantics, type systems, symbolic computation, linking and explicit substitution, in-lining and macros, templates, program transformation o Runtime code generation, compilation, active libraries, synthesis from specifications, development methods, generation of non-code artifacts, formal methods, reflection * Generative techniques for o Product lines and architectures o Embedded systems o Model-driven architecture * Component-based software engineering o Reuse, distributed platforms, distributed systems, evolution, analysis and design patterns, development methods, formal methods * Integration of generative and component-based approaches * Domain engineering and domain analysis o Domain-specific languages (DSLs) including visual and UML-based DSLs * Separation of concerns o Aspect-oriented programming, feature-oriented programming, o Intentional programming, and multi-dimensional separation of concerns * Industrial applications Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. The program committee is happy to advise on the appropriateness of a particular subject. ------------------------------------ Paper Submission ------------------------------------ Authors are invited to submit a title and abstract by March 12, 2004, and a full paper by March 19, 2004. These deadlines are firm. Simultaneous submission to other venues and submission of previously published material are not allowed. Electronic submission will be required, except by special arrangement with the program chairs. Authors will be notified of acceptance by May 17, 2004. Final versions of accepted papers must be submitted by July 25, 2004. Accepted papers will appear in the conference proceedings published in the Springer-Verlag Lecture Notes in Computer Science (LNCS) series http://www.springer.de/comp/lncs/index.html. Submissions must be in PDF, must conform to the LNCS style, and be no longer than 15 pages. For the formatting details see http://www.springer.de/comp/lncs/authors.html. ------------------------------------ Other Contributions ------------------------------------ Work related to generative programming and component engineering can also be presented in other forms than papers. GPCE has separate days for tutorials and workshops. During the conference there are sessions for tool demonstrations and practitioner reports. If you want to organize a workshop, present a tutorial, or demonstration, see the information on the conference website for details about format and submission. Contact the relevant chair for more information. ------------------------------------ Important Dates ------------------------------------ Technical papers * Pre-submission: March 12, 2004 * Submission: March 19, 2004 * Notification: May 17, 2004 * Final version: July 25, 2004 Submissions of proposals * Workshops: March 19, 2004 * Practitioners: April 30, 2004 * Tutorials: April 30, 2004 * Demonstrations: July 2, 2004 Conference * Tutorials: October 24, 2004 * Workshops: October 25, 2004 * Papers: October 26-28, 2004 ------------------------------------ Organization ------------------------------------ General chair * Tim Sheard (OGI School of Science & Engineering at OHSU) Program committee chairs * Gabor Karsai (Vanderbilt University) * Eelco Visser (Utrecht University) Program committee * Uwe Assmann (Linkopings Universitet) * Don Batory (University of Texas) * Jan Bosch (Universiteit Groningen) * Jean Bezivin (Universit� de Nantes) * Jim Cordy (Queen's University) * Krzysztof Czarnecki (University of Waterloo) * Mathew Flatt (University of Utah) * Robert Gl�ck (University of Copenhagen) * George Heineman (Worcester Polytechnic Institute) * Michael Leuschel (University of Southampton) * Karl Lieberherr (Northeastern University) * Simon Peyton Jones (Microsoft Research) * Douglas R. Smith (Kestrel Institute) * Gabriele Taentzer (Technical University of Berlin) * Todd Veldhuizen (Indiana University) * Kris de Volder (University of Britisch Columbia) * Dave Wile (Teknowledge Corp.) * Alexander Wolf (University of Colorado at Boulder) Workshop Chair * Zino Benaissa (Intel) Tutorial Chair * Jeff Gray (University of Alabama at Birmingham) Demonstrations Chair * Simon Helsen (University of Waterloo) Contact * gpce-chairs(a)cs.uu.nl

1 0

RE: Documentation fix for TH example
by Simon Peyton-Jones 04 Feb '04

04 Feb '04

All true! Good suggestions. Are you getting on all right with TH now. The mailing list has been rather quiet recently. Simon | -----Original Message----- | From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs- | bounces(a)haskell.org] On Behalf Of Gregory Wright | Sent: 29 January 2004 22:04 | To: glasgow-haskell-bugs(a)haskell.org | Subject: Documentation fix for TH example | | | Hi, | | The GHC 6.2 User's Guide has some misleading information w.r.t. | template haskell. | | It still uses Expr instead of ExpQ. It refers to Tim Sheard's notes, | but doesn't have the link | | http://research.microsoft.com/~simonpj/tmp/notes2.ps | | It should also warn that not all of the features discussed in the above | notes are implemented. | In particular, the way to get TH is still to import | Language.Haskell.THSyntax, not Language.Haskell.TH. | | The example doesn't compile under 6.2. The attachment corrects this. | | A note that TH is rapidly evolving and that the API is likely to change | incompatibly between | compiler releases might not be out of place either. (I know that such | warnings are present | in the literature and in some places on the mailing list, but language | users who are not | part of the FP community look to the documentation first.) | | Best Wishes, | | Greg | | Gregory Wright | Antiope Associate LLC | 18 Clay Street | Fair Haven, New Jersey 07704 | | gwright(a)antiope.com |

3 3

Re: th package?
by Ian Lynagh 16 Jan '04

16 Jan '04

On Mon, Jan 05, 2004 at 10:04:27AM -0000, Simon Peyton-Jones wrote: > > | From: cvs-all-bounces(a)haskell.org [mailto:cvs-all-bounces@haskell.org] > On Behalf Of Ross Paterson > | > | How about splitting the TH stuff off into a separate package from > | haskell-src? It would simplify things for the other implementations. > > No objections from me. > > Ian, would you care to do this? Done - package name template-haskell. I've noticed that the maintainer for Language.Haskell.TH.Syntax is listed as libraries(a)haskell.org whereas I think template-haskell(a)haskell.org would be better. Does anyone disagree? I'll add module headers to the other files (oh, and I've just noticed the module name of TH.Syntax is wrong) when this is decided. Thanks Ian

1 0

RE: Partial evaluation using TH
by Simon Peyton-Jones 12 Jan '04

12 Jan '04

Duncan Interesting. I'm ccing the TH mailing list. What do TH-afficionados think? Nested brackets ~~~~~~~~~~ | > evalProg' = [| evalProg |] --same evalProg as before | | > compileProg :: ExpQ -> ExpQ | > compileProg = $( cogen [| evalProg' |] ) I'm very keen that TH should obey the beta rule. That is, given x = e you can always replace x by e. So in this case you ought to be able to write compileProg = $(cogen [| [| evalProg |] |]) I'm not saying anything about efficiency yet -- but it ought to be correct. ===> Conclusion 1: TH should allow nested brackets (and presumably nested $'s). Quoting ~~~~~ Consider v1 = [| x * 7 + x |] We get a wodge of syntax tree for v1. But consider this: w = x*7 + x v2 = [| w |] We get a tiny syntax tree for v2. How has this happened? Because every client of v2 (who might say $v) can also "see" w. We can't do this so easily if x is local: v3 x = [| x*7 + x |] Now if we say $(v3 5) we'll get a syntax tree. We can still try lifting the body out: v3 x = let w = x*7 + x in [| w |] Actually this will work if w is "liftable". When we call $(v3 5), we'll build the code [| 40 |]. Hmm. ===> Observation 2. Something I didn't realise: this forces w. So substituting for w might change strictness behaviour. Sigh. However, if w's type is not liftable (e.g. it's Exp, or Tree), then the program will be rejected as ill typed. ====> Observation 3. I wonder if it's a coincidence that you got away with the lift-to-top-level trick. In a more general setting you might not be able to, and then you'd get very heavy encoding. Double encoding ~~~~~~~~~~ You ask for a function enc :: Exp t -> Exp (Exp t) Well that's easy, isn't it? enc x = return x I'm not sure if that's what you want. Indeed, you say " So, the thing that concerns me is the double encoding. I can't intuitively see the need for it..." Maybe you can give the intuition for why you can't see the need for it? I don't think I understand all the issues nearly well enough to comment further. Maybe you can chew on it with Ian, who is pretty au fait with TH. Simon

4 3

FW: Partial evaluation using TH
by Simon Peyton-Jones 01 Jan '04

01 Jan '04

I'm forwarding this rather interesting message to the TH mailing list Simon -----Original Message----- From: Duncan Coutts [mailto:duncan.coutts@worcester.oxford.ac.uk] Sent: 19 December 2003 22:53 To: Ian Lynagh; Simon Peyton-Jones Subject: Partial evaluation using TH Hi Ian, Simon, I've been playing with partial evaluation and am looking at doing partial evaluation for Haskell using Template Haskell. I've come across an issue with which I was hoping you might help me to understand what is going on. I've got a working (trivial) self-applicable partial evaluator using TH. It is a trivial specialiser in the sense that it doesn't do any specialisation, but I'm just looking at the feasibility at the moment. A bit of background; people building partial evaluators like to do this trick where they specialise the specialiser with respect to itself. If the specialiser function is called mix, they do: cogen = mix mix mix This works fine if your in an untyped language. In Haskell you need to use encodings (of encodings) of programs to get a sensible type. Before launching into the TH version, I've got a typed model which is quite useful for seeing what is going on. We model TH's AST data type as a data type with a phantom type parameter which is the type of the value that the AST represents > data Exp t = ... Now we model the |[ ]| and $() operators as functions: > spliceIn :: Exp t -> t > spliceOut :: t -> Exp t Obviously, we can't define these functions. We also have to remember to use them with the same syntactic restrictions as their TH counterparts. Now mix; it takes an expression representing a function and applies it to its static argument. > mix :: Exp (a -> b) -> Exp a -> Exp b We will also need encodings of mix > mix' = spliceOut mix > mix'' = spliceOut mix' So the self application works like so > cogen :: Exp (Exp (a -> b)) -> Exp (Exp a -> Exp b) > cogen = spliceIn(mix mix' mix'') The double encoding on the LHS concerns me somewhat, I'll come back to that. We can now use this function to build a compiler for an embeded language given an interpreter for that language. Suppose I've got some trivial imperative language and an interpreter for it (evalProg takes a Prog AST an initial value assignment of variables and returns the result of running the program) > evalProg :: Prog -> State -> Value Then a compiler function for this language can be defined as > comp :: Exp Prog -> Exp (State -> Value) > comp = spliceIn (cogen (spliceOut (spliceOut evalProg))) Note the use of the double encoding. Finally, the compiler function can be used to compile a program in this trivial language into a Haskell function: > prog :: Prog > prog = [Return (Var "a")] > target :: State -> Value > target = spliceIn (comp (spliceOut prog)) We can translate this in a straightforward way into TH. For this brief presentation I'll pretend we don't have any staging restrictions (in reality it is spread over 6 modules). > mix :: ExpQ -> ExpQ -> ExpQ > mix f x = f `app` x --trivial specialiser > mix', mix'' :: ExpQ > mix' = [| mix |] > mix'' = [| mix' |] > cogen :: ExpQ -> ExpQ > cogen = $(mix mix' mix'') > evalProg' = [| evalProg |] --same evalProg as before > compileProg :: ExpQ -> ExpQ > compileProg = $( cogen [| evalProg' |] ) Again, note the double encoding of evalProg. > prog :: Prog > prog = [Return (Var "a")] > target :: State -> Value > target = $(compileProg [| prog |]) And it works: *THTest> target [("a", 5)] 5 So, the thing that concerns me is the double encoding. I can't intuitively see the need for it and it is certianly a pain to have to do whenever one uses cogen. On the other hand, there's no real performance overhead due to the double encoding (as there is usually when self-applying partial evaluators in typed languages) because if we look at evalProg' and evalProg'' we see: evalProg' = return $ Var "Interp:evalProg" [| evalProg' |] = return $ Var "Interp1:evalProg'" (in contrast, in normal typed partial evaluators you can end up with a massive amount of extra storage taken up by the double encoding) I'm wondering if there is any way to write a function Exp t -> Exp (Exp t) So that the result must be spliced in twice to get a value of type t (Again, I'm using a phantom type to indicate what is going on.) That way one could use cogen: compileProg = $( cogen [| evalProg |] ) rather than compileProg = $( cogen [| [| evalProg |] |] ) (I know you can't nest [||], but that's sort of what we're doing) Any ideas? Why does the double encoding occur? Does it make any sense in TH? Can I elimiate/hide it? Duncan -- Duncan Coutts, BA Probationary Research Student in Computer Science University of Oxford

1 0

type classes and template haskell (bug?)
by Jeremy Shaw 25 Dec '03

25 Dec '03

Hello, I have a file that contains the following, which I have loaded into ghci 6.2: module Main where import Language.Haskell.THSyntax class Test a where test :: a -> a instance Test (a,b,c) where test x = x main = putStrLn "Hello, World!" Now, the following works for me: *Main> runQ [d| instance Test (Int,Int) |] >>= putStrLn . show [InstanceD [] (AppT (ConT "Main:Test") (AppT (AppT (TupleT 2) (ConT "GHC.Base:Int")) (ConT "GHC.Base:Int"))) []] But this doesn't: *Main> runQ [d| instance Test (a,b) |] >>= putStrLn . show ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): Failed binder lookup: a {- tv a20x -} Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. Am I doing something wrong, or is this a bug? Thanks! Jeremy Shaw. ps. sorry if you get this message twice, I sent it once, but I had signed up on the mailing list with the wrong email address. So, I changed my account settings to have my correct email address, but now I can't cancel the message that is awaiting moderator approval.

1 0

Big TH commit
by Simon Peyton-Jones 18 Dec '03

18 Dec '03

OK, I've committed the new TH stuff. There is still more to do, but lots of stuff works that didn't before (summarised below). One thing that's a bit "off" at the moment is that I'm using the type checker's own monad to generate uniques for TH. As a result, if you print out the TH-generated code, you get stuff like data TH_reifyDecl1.R a_1627393116 = TH_reifyDecl1.C a_1627393116 Now there's nothing wrong with this, but it might make sense for the pretty-printer (now in THLib) to clean it up. I'm hoping that Ian or someone will do that task -- it's quite clearly separated. Meanwhile, please do beat on this new stuff. It's really a big step forward I think. Simon -----Original Message----- From: cvs-all-bounces(a)haskell.org [mailto:cvs-all-bounces@haskell.org] On Behalf Of Simon Peyton Jones Sent: 06 November 2003 17:10 To: cvs-ghc(a)haskell.org; cvs-fptools(a)haskell.org; cvs-libraries(a)haskell.org Subject: cvs commit: fptools/ghc/compiler/basicTypes Name.lhs OccName.lhs RdrName.lhs UniqSupply.lhs Unique.lhs Var.lhs fptools/ghc/compiler/deSugar DsExpr.lhs DsForeign.lhs DsMeta.hs DsMonad.lhs fptools/ghc/compiler/hsSyn Convert.lhs HsExpr.lhs ... simonpj 2003/11/06 09:10:01 PST Modified files: ghc/compiler/basicTypes Name.lhs OccName.lhs RdrName.lhs UniqSupply.lhs Unique.lhs Var.lhs ghc/compiler/deSugar DsExpr.lhs DsForeign.lhs DsMeta.hs DsMonad.lhs ghc/compiler/hsSyn Convert.lhs HsExpr.lhs ghc/compiler/iface LoadIface.lhs ghc/compiler/main ErrUtils.lhs ghc/compiler/parser Lexer.x Parser.y ghc/compiler/prelude PrelNames.lhs ghc/compiler/rename RnEnv.lhs RnExpr.lhs RnSource.lhs ghc/compiler/typecheck TcClassDcl.lhs TcExpr.lhs TcHsSyn.lhs TcHsType.lhs TcRnDriver.lhs TcRnMonad.lhs TcSplice.lhs TcUnify.lhs ghc/compiler/utils UniqFM.lhs testsuite/tests/ghc-regress/th TH_bracket3.hs TH_reifyDecl1.hs TH_reifyType1.hs TH_reifyType2.hs TH_repE1.hs TH_repE2.hs TH_repE3.hs TH_repPrim.hs TH_repPrim.stderr TH_repPrimOutput.hs TH_spliceDecl1.hs TH_spliceDecl2.hs TH_spliceDecl3.hs TH_spliceDecl3_Lib.hs TH_spliceE3.hs TH_spliceExpr1.hs all.T libraries/haskell-src Makefile Added files: testsuite/tests/ghc-regress/th TH_reifyDecl1.stderr TH_spliceE1.hs TH_spliceE1.stdout libraries/haskell-src/Language/Haskell TH.hs libraries/haskell-src/Language/Haskell/TH THLib.hs THSyntax.hs Removed files: testsuite/tests/ghc-regress/th TH_reifyDecl2.hs TH_reifyDecl3.hs TH_reifyDecl4.hs libraries/haskell-src/Language/Haskell THSyntax.hs Log: ------------------------------------ Major increment for Template Haskell ------------------------------------ 1. New abstract data type "Name" which appears where String used to be. E.g. data Exp = VarE Name | ... 2. New syntax 'x and ''T, for quoting Names. It's rather like [| x |] and [t| T |] respectively, except that a) it's non-monadic: 'x :: Name b) you get a Name not an Exp or Type 3. reify is an ordinary function reify :: Name -> Q Info New data type Info which tells what TH knows about Name 4. Local variables work properly. So this works now (crashed before): f x = $( [| x |] ) 5. THSyntax is split up into three modules: Language.Haskell.TH TH "clients" import this Language.Haskell.TH.THSyntax data type declarations and internal stuff Language.Haskell.TH.THLib Support library code (all re-exported by TH), including smart constructors and pretty printer 6. Error reporting and recovery are in (not yet well tested) report :: Bool {- True <=> fatal -} -> String -> Q () recover :: Q a -> Q a -> Q a 7. Can find current module currentModule :: Q String Much other cleaning up, needless to say. Revision Changes Path 1.107 +1 -1 fptools/ghc/compiler/basicTypes/Name.lhs 1.56 +10 -4 fptools/ghc/compiler/basicTypes/OccName.lhs 1.26 +3 -3 fptools/ghc/compiler/basicTypes/RdrName.lhs 1.32 +2 -2 fptools/ghc/compiler/basicTypes/UniqSupply.lhs 1.69 +11 -8 fptools/ghc/compiler/basicTypes/Unique.lhs 1.33 +8 -8 fptools/ghc/compiler/basicTypes/Var.lhs 1.103 +1 -2 fptools/ghc/compiler/deSugar/DsExpr.lhs 1.81 +2 -2 fptools/ghc/compiler/deSugar/DsForeign.lhs 1.48 +318 -296 fptools/ghc/compiler/deSugar/DsMeta.hs 1.51 +4 -2 fptools/ghc/compiler/deSugar/DsMonad.lhs 1.41 +79 -74 fptools/ghc/compiler/hsSyn/Convert.lhs 1.88 +0 -19 fptools/ghc/compiler/hsSyn/HsExpr.lhs 1.5 +1 -1 fptools/ghc/compiler/iface/LoadIface.lhs 1.42 +2 -10 fptools/ghc/compiler/main/ErrUtils.lhs 1.15 +61 -31 fptools/ghc/compiler/parser/Lexer.x 1.129 +9 -13 fptools/ghc/compiler/parser/Parser.y 1.83 +0 -3 fptools/ghc/compiler/prelude/PrelNames.lhs 1.171 +18 -22 fptools/ghc/compiler/rename/RnEnv.lhs 1.125 +2 -6 fptools/ghc/compiler/rename/RnExpr.lhs 1.162 +3 -0 fptools/ghc/compiler/rename/RnSource.lhs 1.137 +1 -1 fptools/ghc/compiler/typecheck/TcClassDcl.lhs 1.161 +0 -12 fptools/ghc/compiler/typecheck/TcExpr.lhs 1.94 +0 -2 fptools/ghc/compiler/typecheck/TcHsSyn.lhs 1.7 +1 -3 fptools/ghc/compiler/typecheck/TcHsType.lhs 1.53 +1 -0 fptools/ghc/compiler/typecheck/TcRnDriver.lhs 1.28 +5 -2 fptools/ghc/compiler/typecheck/TcRnMonad.lhs 1.28 +232 -120 fptools/ghc/compiler/typecheck/TcSplice.lhs 1.52 +1 -1 fptools/ghc/compiler/typecheck/TcUnify.lhs 1.37 +16 -16 fptools/ghc/compiler/utils/UniqFM.lhs 1.2 +1 -0 fptools/testsuite/tests/ghc-regress/th/TH_bracket3.hs 1.4 +30 -14 fptools/testsuite/tests/ghc-regress/th/TH_reifyDecl1.hs 1.4 +3 -3 fptools/testsuite/tests/ghc-regress/th/TH_reifyType1.hs 1.4 +3 -3 fptools/testsuite/tests/ghc-regress/th/TH_reifyType2.hs 1.3 +1 -1 fptools/testsuite/tests/ghc-regress/th/TH_repE1.hs 1.2 +1 -1 fptools/testsuite/tests/ghc-regress/th/TH_repE2.hs 1.2 +1 -1 fptools/testsuite/tests/ghc-regress/th/TH_repE3.hs 1.4 +11 -12 fptools/testsuite/tests/ghc-regress/th/TH_repPrim.hs 1.4 +6 -6 fptools/testsuite/tests/ghc-regress/th/TH_repPrim.stderr 1.5 +2 -10 fptools/testsuite/tests/ghc-regress/th/TH_repPrimOutput.hs 1.5 +2 -2 fptools/testsuite/tests/ghc-regress/th/TH_spliceDecl1.hs 1.3 +1 -2 fptools/testsuite/tests/ghc-regress/th/TH_spliceDecl2.hs 1.3 +2 -2 fptools/testsuite/tests/ghc-regress/th/TH_spliceDecl3.hs 1.5 +4 -4 fptools/testsuite/tests/ghc-regress/th/TH_spliceDecl3_Lib.hs 1.2 +1 -1 fptools/testsuite/tests/ghc-regress/th/TH_spliceE3.hs 1.3 +1 -1 fptools/testsuite/tests/ghc-regress/th/TH_spliceExpr1.hs 1.15 +3 -4 fptools/testsuite/tests/ghc-regress/th/all.T 1.9 +2 -2 fptools/libraries/haskell-src/Makefile _______________________________________________ Cvs-libraries mailing list Cvs-libraries(a)haskell.org http://www.haskell.org/mailman/listinfo/cvs-libraries

2 1