November 2003 - template-haskell

RE: [Template-haskell] TH stability and support
by Simon Peyton-Jones 17 Nov '03

17 Nov '03

The broad outlines of TH are stable, but there are likely to be changes. For example, the details of the data type representing Haskell terms might change. But I don't think anything significant will disappear -- new stuff may well appear. Yes, we do plan to support TH in GHC for the foreseeable future. As to other implementations, remember the economics of compilers. All Haskell implementations are built and maintained by volunteers. Within the effort budget we can individually afford, we each adjust our priorities based in part on what our users want. If lots and lots of people start using TH and ask for it in (say) Hugs, that'll make it more likely that it'll get done. But it's not a small feature to add, so I wouldn't plan on it any time soon. Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Wolfgang Jeltsch | Sent: 15 November 2003 13:46 | To: Template Haskell Mailing List | Subject: [Template-haskell] TH stability and support | | Hello, | | is Template Haskell likely to be implemented in Hugs and/or NHC in the nearer | future? I think, TH could be very useful for me but actually I don't want to | restrict myself to a certain compiler/interpreter. Can I be sure that TH will | continue to be supported by GHC? | | I addition, I'd like to know if TH is rather stable now or if its interface | will make bigger changes in the future. | | Ciao, Wolfgang | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

TH stability and support
by Wolfgang Jeltsch 15 Nov '03

15 Nov '03

Hello, is Template Haskell likely to be implemented in Hugs and/or NHC in the nearer future? I think, TH could be very useful for me but actually I don't want to restrict myself to a certain compiler/interpreter. Can I be sure that TH will continue to be supported by GHC? I addition, I'd like to know if TH is rather stable now or if its interface will make bigger changes in the future. Ciao, Wolfgang

1 0

Module THTraverse
by Sean Seefried 14 Nov '03

14 Nov '03

A common task when using Template Haskell is to write some sort of transformation pass over a THSyntax data type. It will typically have the form: thPass :: <data-type> -> Q <data-type> where data-type is any one of Dec, Exp, Typ etc. In fact, writing a pass usually involves writing functions for more than one of the data types, since the data types are heavily interrelated. This presents a little bit of a conundrum for programmers. The interesting work of the pass may well only be on expressions (the Exp data type), but you may want to call the pass on declarations (Dec). But this means one has to write a whole bunch of cases that do nothing but call the pass recursively on the substructures of declarations. Worse still, it is necessary to write functions to traverse these substructures since they may not be expressions, but contain expressions. I could see this task being repeated over and over again, so I did what any good programmer would do and wrote a module to relieve the burden of writing the recursive cases, which I have called THTraverse. I will show how to use the module through an example. Say we wish to write a pass that does just one thing: it traverses through declarations and changes all sub-expressions which use infix function application to prefix form. For example, the following expression: InfixE (Just (VarE "x")) (VarE "fun") (Just (VarE "y")) becomes AppE (AppE (VarE "fun") (VarE "x")) (VarE "y") First, I'm going to throw you all in the deep end by showing the full definition of this function using the THTraverse module. Then, once you begun to drown in the definition, I'll throw in some floatation devices (i.e. explanation and clarification) to help you swim again. Here is the full definition of infixToPrefixDec ------------------------- infixToPrefixFuns :: THTraverseFuns Q infixToPrefixFuns = (THTraverseFuns i i i i i i i i i i i i i i i i i i i i i i) { tDec = infixToPrefixDec, tExp = infixToPrefixExp } where i item = thTraverse infixToPrefixFuns item infixToPrefixDec dec = thTraverse infixToPrefixFuns dec infixToPrefixExp (InfixE (Just e1) e2 (Just e3)) = do e1' <- thTraverse infixToPrefixFuns e1 e2' <- thTraverse infixToPrefixFuns e2 e3' <- thTraverse infixToPrefixFuns e3 return $ AppE (AppE e1' e2') e3' where infixToPrefixExp exp = thTraverse infixToPrefixFuns exp ------------------------- I hope you will agree that this constitutes a lot less programming. Now for the explanation of how it all works. The heart of the module is the function thTraverse which is defined using type classes. class THTraverse a where thTraverse :: Monad m => THTraverseFuns m -> a -> m a (Usually the monad will be the Q monad but this does not have to be the case. I often find myself using the Identity monad.) An instance of the class has been defined for all the data types declared in THSyntax. The function, thTraverse, has one very simple purpose; to take an instance of the THTraverseFuns data structure, and an instance of a THSyntax data structure (call it "d"), and to call the appropriate functions recursively on the sub-structures of "d". The appropriate functions are contained within an instance of THTraverseFuns. Its definition is: data THTraverseFuns m = THTraverseFuns { tLit :: Lit -> m Lit, tPat :: Pat -> m Pat, tFieldPat :: FieldPat -> m FieldPat, tMatch :: Match -> m Match, tClause :: Clause -> m Clause, tGuardedExp :: (Exp, Exp) -> m (Exp,Exp), tExp :: Exp -> m Exp, tFieldExp :: FieldExp -> m FieldExp, tBody :: Body -> m Body, tStmt :: Stmt -> m Stmt, tRange :: Range -> m Range, tDec :: Dec -> m Dec, tForeign :: Foreign -> m Foreign, tCallconv :: Callconv -> m Callconv, tSafety :: Safety -> m Safety, tCxt :: Cxt -> m Cxt, tStrict :: Strict -> m Strict, tCon :: Con -> m Con, tStrictType :: StrictType -> m StrictType, tVarStrictType :: VarStrictType -> m VarStrictType, tModule :: Module -> m Module, tType :: Type -> m Type } When defining a traversal function, thTraverse should be used as a catch-all case once the cases that actually do useful work have been written. As such, a call to thTraverse should be the last case of any traversal function definition. You can see this in the function definitions for infixToPrefixDec and infixToPrefixExp above. When writing a function in which all you want to do is recursively call the pass on the sub-structures the thTraverse case will be the only case. If we now to return to the example, we can see that for the most part infixToPrefixFuns is defined in terms of 'i', which just calls thTraverse on sub-structures. (Note the recursive nature of its definition; thTraverse is applied to infixToPrefixFuns.) This saves much of the work of writing out tedious functions which contain only one case. There is now only one thing to clarify. Why did I define infixToPrefixDec if it only contains the thTraverse case? Why, so I had a name to refer to it. Nothing else. ------------------------- Summary. To write your own pass follow this simple recipe: 1. Declare a function <name>Funs = (THTraverseFuns i i i i i i i i i i i i i i i i i i i i i i) { < functions you defined in step 2 will go here > } where i item = thTraverse infixToPrefixFuns item 2. Write the functions of the pass that actually do interesting work. Ensure that the last case is a call to thTraverse of the form. <pass function> x = thTraverse <name>Funs x 3. Back substitute the names of these pass functions back into the definition of 1. ------------------------- I realise acutely that it may be possible to write the THTraverse module. For instance, I find that the necessity of a THTraverseFuns data structure annoying. I would have preferred to define the function thTraverse without its use. I thought that it might be possible to do this through the use of type classes but I was unable to do this. I urge the more zealous hackers out there to have a look at my module and see if they can do better.

2 1

RE: [Template-haskell] TH version 2
by Simon Peyton-Jones 10 Nov '03

10 Nov '03

Sorry about that -- now fixed. Simon | -----Original Message----- | From: kyra [mailto:kyrab@mail.ru] | Sent: 08 November 2003 10:26 | To: Simon Peyton-Jones; template-haskell(a)haskell.org | Subject: Re: [Template-haskell] TH version 2 | | It seems http://research.microsoft.com/~simonpj/tmp/notes2.ps points to | nowhere. |

1 0

TH version 2
by Simon Peyton-Jones 08 Nov '03

08 Nov '03

Folks Further to recent to-ing and fro-ing, I have now a) Committed the most recent version of TH to the HEAD. You'll have to build from source to get it, or grab a development snapshot b) Brought the "notes" document more or less up to date http://research.microsoft.com/~simonpj/tmp/notes2.ps Do have a read of the new "notes". It's quite a bit more coherent than before. There are chunks that are not yet implemented (notably, splicing into binding positions), and differences of detail (e.g. the error reporting). But the new Name stuff is all there, and the new reification stuff. Type splices next (should not take long). Many long-standing bugs are fixed. For example f x = $( [| x |] ) now works (and more interesting examples with similar flavour). Please send feedback to the list. Simon

2 1

RE: [Template-haskell] program transformation
by Simon Peyton-Jones 07 Nov '03

07 Nov '03

I'm returning to the question of reification in Template Haskell. Would it help here if one could say reify :: Var -> Q Decl and get the declaration for 'reverse'? (Var is as in the "notes" Postscript file I posted yesterday.) I can arrange that iff reverse is defined in the same module. Thus reverse = ... foo = $( do { rev_dec <- reify 'reverse; ... }) (The 'reverse is like a quote [|reverse|], but gets a Var not an Exp.) This is much harder if reverse is imported, because we simply don't have access to reverse's source code any more. (But type constructors and classes are fine. -- excluding the default-method bindings of the class.) Would this help? Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Ganesh Sittampalam | Sent: 12 September 2003 17:10 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] program transformation | | I'm currently investigating the possibility of redoing MAG in Template | Haskell. MAG is essentially (at least for the purposes of this email) a | system that takes a source program and a bunch of rewrite rules, and | applies the rewrite rules to the program. | | I'd like to be able to do this in TH with as little syntactic noise for | the user as possible. The general idea (at the moment) would be to put the | original program within [d| |] brackets, the set of rewrite rules within | [| |] brackets, run a function on the two and splice in the result. | | It's not the main purpose of this email, but I should mention that being | able to splice in code in the same module as it is defined would be very | useful for this application, since otherwise any module that makes use of | this will need to be split into two. | | There was a previous discussion about TH and Hydra at | http://www.haskell.org/pipermail/template-haskell/2003-January/000008.ht ml, | which ended up with the idea of using [d| |] brackets for code that was to | be transformed. The extra twist for me is that I have this set of rewrite | rules that I also want to use quasi-quotes for. | | A simplified example of a rewrite rule that uses the associativity of (++) | is as follows: | | \xs ys zs -> (xs ++ ys) ++ zs ==> xs ++ (ys ++ zs) | | ==> is an operator of type a -> a -> RewriteRule, so GHC will check for me | that the rewrite rule is type correct. The lambda binding for xs, ys and | zs specifies that the rewrite rule works for any value of them, and also | keeps the compiler happy that I haven't used undefined variables. Of | course, I'm never intending to actually run this code, I'll just use the | result of quasi-quoting it to apply transformations. | | Anyway, this all works fine. Now, let's suppose that my original program | defines the function reverse (hiding the Prelude reverse function), and I | want to write a rewrite rule mentioning reverse too. I end up with | something like this: | | reversecode = | [d| | reverse [] = [] | reverse (x:xs) = reverse xs ++ [x] | |] | | rules = [| [ reverse [] ==> [] ] |] | | The second definition won't compile, since reverse isn't in scope | anywhere. I'm trying to work out a good solution to this problem; so far | I've come up with the following ideas: | | (a) Merge the rewrite rules and the declarations. E.g: | [| | let reverse [] = [] | reverse (x:xs) = reverse xs ++ [x] | in [ reverse [] ==> [] | ... | ] | |] | Pros: - this should actually work for me right now (not actually tested | - though) | Cons: - it violates the nice separation between code and transformation, | - it doesn't read nicely for the user; in particular it'll be | unpleasant for them to take some existing code and decide to use | MAG on it | | (b) Use a lambda-abstraction or let-binding to make "reverse" appear to be | defined. | Pros: - again this ought to work right now | Cons: - unless I textually duplicate code, it won't be properly type-checked | - the renamer will rename "reverse" and I'll have to make some | nasty assumptions about how that works to get back to the | original form | | (c) Turn the rewrite rules into a separate [d| |] block, and splice in | $(reversecode) at the beginning | Pros: - Not nearly as inelegant/nasty as (a) or (b) | Cons: - I still have to search the declaration list for the rewrite | rules | - This will fall foul of the (second) bug I reported yesterday | | (d) Say something like let $(reversecode) in reverse [] ==> [] | Pros: - Seems even less nasty than the above options | Cons: - disallowed by design in TH, for good reasons; it destroys the | ability to see where things are bound statically | | I'd appreciate any comments or alternative suggestions. Ideally I think | I'm looking for some nice concise way to say that the rewrite rules | quasi-quotes should be parsed and type-checked in the context of the | declarations in original code quasi-quotes. | | Cheers, | | Ganesh | | | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1

RE: [Template-haskell] Reification
by Simon Peyton-Jones 06 Nov '03

06 Nov '03

| > reify :: Var -> Q Dec | | I still prefer "Name" to "Var" (assuming I'm not confused and you can | give it the name of a class, type or whatever). Yes, you may be right. I'd be interested to hear other opinions. These naming issues are always contentious. Remember that this new data type (Var or Name or whatever we decide to call it) is pretty ubiquitous. It's going to replace pretty much all the occurrences of String in the Exp, Dec etc data types. E.g. data Exp = Var Name | Lam Name Exp etc Simon

2 1

RE: [Template-haskell] Reification
by Simon Peyton-Jones 06 Nov '03

06 Nov '03

| What would be most flexible for the user is to return the best | information that is available. In the example: | | >NB This can apply to top-level decls too: | > f = 1+2 | > $( ... reify 'f... ) | > g = f + (4::Int) | > | >Because of the monomorphism restriction, the type of f is fixed by f's | >caller, which may be "after" the reification. | > | it might still be useful to find out that an approximation to the type | is f :: Num a => a, even though that isn't the final type. That would | suggest something like | | data TypeQuery a = ExactType a | ApproximationType a Actually, I was thinking of something more modest. The type of f will, at the stage of reification, be a -> a where a is an as-yet-refined internal type variable. If instead we had id x = x the type would be forall a. a->a So I'm thinking that if the Type returned to you by TH contains free type variables, that might simply signify types that might be later refined. Simple. But not very principled, because the type you see will depend on which order the type checker happens to do its work in. Simon

3 3

Reification
by Simon Peyton-Jones 06 Nov '03

06 Nov '03

Folks I'm on the TH warpath, and I'm working on reification. The idea is that 'reify' is not a language construct any more: it's just an ordinary function reify :: Var -> Q Dec This is much better that what we have now, because when you walk over the Dec you may find more Vars, and now you can reify them in turn. Which you absolutely cannot do today. To invoke reify in the first place, you need a Var, and you can get one using the new quote syntax. e.g. reify 'map will give you the declaration for map. In general 'map is very like [| map |], except you get a Var instead of a Q Exp. So (a) it's not monadic, which is jolly convenient, and (b) it gives you the Var v directly rather than a (VarE v), which is also convenient. But it has all the same staging rules as [| ... |]. Question 1 ~~~~~~~ You probably want more info than just the declaration. For functions you'd like to know the type and fixity... so we could instead have reify :: Var -> Q Info data Info = Class Decl | TyCon Decl | Var Type Decl Fixity | DataCon Type Var {- parent tycon -} Fixity | ClassOp Type Var {- parent class -} Fixity | Unknown Would that be a better plan? One could have reifyFixity, reifyType, etc, to get the anciliary bits, but it seems nicer to get the whole lot in one go. It's a bit unclean that given (Class d) it'd be certain that d was of the form ClassD. Any better ideas? Question 2 ~~~~~~~ The type checker may not know the full type of the thing. For example: f x = $( do { i <- reify 'x; ... } ) ..... The type of 'x' isn't known yet. It may get refined by the other "..." parts of f's body, or by f's use. So should we give up and refuse to give you f's type? Or what? NB This can apply to top-level decls too: f = 1+2 $( ... reify 'f... ) g = f + (4::Int) Because of the monomorphism restriction, the type of f is fixed by f's caller, which may be "after" the reification. I'm really not sure what to do here. Simon PS: I've implemented most of this stuff, but I'm holding off committing for fear of annoying those of you using current TH. But I'd like to commit soon. Perhaps anyone wanting a stable TH can use the 6.2 branch? Would that do?

3 2

RE: [Template-haskell] RE: Template Haskell...
by Simon Peyton-Jones 03 Nov '03

03 Nov '03

Not so. We split at top-level declaration splices. What about this, though? NO splitting involved. f :: Int -> Q Exp f n = [| n+2 |] g x = x + $(f 3) Furthermore, we don't want to *always* compile-to-byte-code all the preceding code in a module. usually none of it'll b needed S | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Alastair Reid | Sent: 31 October 2003 17:35 | To: Simon Peyton-Jones; MR K P SCHUPKE; template-haskell(a)haskell.org | Subject: Re: [Template-haskell] RE: Template Haskell... | | On Friday 31 October 2003 5:24 pm, Simon Peyton-Jones wrote: | > Trouble is, that's thoroughly awkward one to implement, because it means | > compiling the transitive closure of all the things in this module | > referred to by the bit you are running. I'm sure it's doable, but I'm | > not looking fwd to it. | | I can see that compiling a module one set of declaration groups at a time | won't be much fun but given the way you split modules into lists of | declaration groups separated by top-level splices, it seems easy enough to | know what to compile: | | You have to compile all the code above the current top-level | splice or declaration group. | | -- | Alastair Reid | | | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1