June 2004 - template-haskell

RE: [Template-haskell] Reification of local names
by Simon Peyton-Jones 22 Jun '04

22 Jun '04

| > One idea: add (Maybe Type) fields to many TH syntax forms, where the | > type checker can record types. That's simple and direct. | | This is actually the way how we implemented it in Nemerle. Our syntax trees | has elements like E_typed { body : Typedtree.Expr } in Parsetree.Expr or | T_typed { body : Typedtree.Type } in Parsetree.Type, so we can store typed | parts in our ASTs. | Our quotations support this with | <[ $(e : typed) ]> where `e' is a variable holding typed tree of expression | | We can also build typed trees for types with quotation like | <[ ttype: int ]> Interesting ... but I'm afraid I don't understand what these notations mean. Suppose you want to build a data structure from the original constructors, by hand as it were. (Which Template Haskell certainly allows you to do.) You don't want to supply all the types! If pattern match over this structure, you aren't going to see types. So the types must somehow be optional. I don't want to have two completely different, but similar, data structures, one with types and one without. Hence the 'Maybe' part. Is that what you have? Simon

2 1

RE: [Template-haskell] Reification of local names
by Simon Peyton-Jones 22 Jun '04

22 Jun '04

You're trying to use reify for something it's not designed for. reify looks something up in the type environment, *at the point where that Q computation was spliced in*. So if I say foo :: Q Info foo = reify (mkName "wog") then the reify will look up "wog" wherever I say $foo. Not at the point where foo is defined. In this case, you're going to look up the name in your syntax tree, but you'll look it up in the type environment where $foo is spliced in -- which is the top level of module A. The "right place" to find the type info for a given syntax tree is in the syntax tree. The type checker has processed your fragment [| let f = \x -> x + 2 in f |] You just want to see the types. Currently there is no way to do that, but people often ask for it. One idea: add (Maybe Type) fields to many TH syntax forms, where the type checker can record types. That's simple and direct. A general question to TH aficionados: would this be useful? Remember that the type may not be fully precise, because it's the result of type-checking an as-yet-unspliced fragment. Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Stefan Heimann | Sent: 17 June 2004 15:46 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] Reification of local names | | Hi! | | I need to extract some type information from the syntax | tree. Therefore I need to reify non-global names. Take the following | example: | | module A where | | import Language.Haskell.TH | | logQ = runIO . putStrLn | | stringOfInfo (ClassI _) = "ClassI" | stringOfInfo (ClassOpI name t _ _) = "ClassOpI " ++ show name ++ " :: " ++ show t | stringOfInfo (TyConI _) = "TyConI" | stringOfInfo (DataConI name t _ _) = "DataConI " ++ show name ++ " :: " ++ show t | stringOfInfo (VarI name t _ _) = "VarI " ++ show name ++ " :: " ++ show t | stringOfInfo (TyVarI name t) = "TyVarI " ++ show name ++ " = " ++ show t | | foo :: Q Exp -> Q [Dec] | foo e' = do e <- e' | case e of | LetE _ (VarE name) -> do info <- reify name | logQ (stringOfInfo info) | return [] | --- | | module Main where | | import A | | $(foo [| let f = \x -> x + 2 | in f |]) | | main = return () | | --- | | What the example does is trying to reify 'f' in the expression | | let f = \x -> x + 2 | in f | | When I now compile the example, I get the following output: | | $ ghc-cvs --make -fth B.hs | Chasing modules from: B.hs | Compiling A ( ./A.hs, ./A.o ) | Compiling Main ( B.hs, B.o ) | Loading package base ... linking ... done. | Loading package haskell98 ... linking ... done. | Loading package template-haskell ... linking ... done. | | B.hs:1:0: tcLookupGlobal: `f' is not in scope | | B.hs:1:0: | Exception when trying to run compile-time code: | Code: foo ([| let f = \ x -> ... in f |] | where []) | Exn: user error (IOEnv failure) | | I am using the development snapshot ghc-6.3.20040612. | | So my question is: Is it simply not possible to reify local | definitions, is it a bug or is it not yet implemented? If it is | possible in general to reify local definitions but just not | implemented at the moment, do you have any schedule on when an | implementation will be available? | | Thanks for helping! | | Stefan | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

4 3

RE: FW: TH quasi-quoting bug - fails on quoting where clause inlet declcontext
by Simon Peyton-Jones 22 Jun '04

22 Jun '04

Yes, same deal. Reifying a tycoon gives you a Dec, and that could easily be decorated with (Maybe Kind) additions. The Maybe is so that when you construct a Dec yourself by hand, you don't have to supply the kind information. Simon | -----Original Message----- | From: Duncan Coutts [mailto:duncan.coutts@worcester.oxford.ac.uk] | Sent: 22 June 2004 13:38 | To: Simon Peyton-Jones | Subject: Re: FW: TH quasi-quoting bug - fails on quoting where clause inlet declcontext | | Cheers Simon. | | BTW, Ian and I were looking the other day at how easy/difficult it would | be to get kind information when we reify type names. Does ghc have that | information readily available, or is it not so easy? | | Duncan | | On Tue, 2004-06-22 at 10:50, Simon Peyton-Jones wrote: | > I don't know if I ever mentioned, but I fixed this a while back | > | > SImon | > | > -----Original Message----- | > From: Simon Marlow | > Sent: 18 June 2004 09:43 | > To: Simon Peyton-Jones | > Subject: FW: TH quasi-quoting bug - fails on quoting where clause in let | > declcontext

1 0

Reification of local names
by Stefan Heimann 17 Jun '04

17 Jun '04

Hi! I need to extract some type information from the syntax tree. Therefore I need to reify non-global names. Take the following example: module A where import Language.Haskell.TH logQ = runIO . putStrLn stringOfInfo (ClassI _) = "ClassI" stringOfInfo (ClassOpI name t _ _) = "ClassOpI " ++ show name ++ " :: " ++ show t stringOfInfo (TyConI _) = "TyConI" stringOfInfo (DataConI name t _ _) = "DataConI " ++ show name ++ " :: " ++ show t stringOfInfo (VarI name t _ _) = "VarI " ++ show name ++ " :: " ++ show t stringOfInfo (TyVarI name t) = "TyVarI " ++ show name ++ " = " ++ show t foo :: Q Exp -> Q [Dec] foo e' = do e <- e' case e of LetE _ (VarE name) -> do info <- reify name logQ (stringOfInfo info) return [] --- module Main where import A $(foo [| let f = \x -> x + 2 in f |]) main = return () --- What the example does is trying to reify 'f' in the expression let f = \x -> x + 2 in f When I now compile the example, I get the following output: $ ghc-cvs --make -fth B.hs Chasing modules from: B.hs Compiling A ( ./A.hs, ./A.o ) Compiling Main ( B.hs, B.o ) Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package template-haskell ... linking ... done. B.hs:1:0: tcLookupGlobal: `f' is not in scope B.hs:1:0: Exception when trying to run compile-time code: Code: foo ([| let f = \ x -> ... in f |] where []) Exn: user error (IOEnv failure) I am using the development snapshot ghc-6.3.20040612. So my question is: Is it simply not possible to reify local definitions, is it a bug or is it not yet implemented? If it is possible in general to reify local definitions but just not implemented at the moment, do you have any schedule on when an implementation will be available? Thanks for helping! Stefan

1 0

instance of Lift for Exp
by Duncan Coutts 08 Jun '04

08 Jun '04

Hi all, the Exp type is not an instance of the Lift class. This is the sensible thing most of the time so that you do not lift an expression when you meant to splice it instead. However in my experience it's sometimes useful (particularly when writing code that generates code), so attached is a module which makes it an instance. Like Text.Show.Functions, you should only import it if you want it, not import it by default. If people find this useful, I'd be quite happy to have it added to the standard GHC TH libs. I've named it Language.Haskell.TH.LiftExp and released it under GHC's BSD-style licence. Issues: * At the moment it also exports instances for Ratio, Maybe, PackedString, (,) and (,,). In my opinion these instances should be exported from Language.Haskell.TH already in which case they could be deleted from this module. (Exporting the instance for PackedString and Ratio is not strictly necessary and perhaps not desirable.) * The encoding for unboxed integers is not pleasant. (Unboxed Ints are used in the definition of Name). If anyone can find a more straightforward encoding please tell me. Duncan

1 0