- template-haskell - Haskell.org

RE: [Template-haskell] instance of Lift for Exp
by Simon Peyton-Jones 21 Jul '04

21 Jul '04

Thanks for the offer. Has anyone else encountered a need for this? Duncan, would you like to give some motivating examples? For the present, I'm inclined to leave it as a user library. Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Duncan Coutts | Sent: 08 June 2004 19:45 | To: Template Haskell List | Subject: [Template-haskell] instance of Lift for Exp | | 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

2 1

RE: calling fail in Q monad gives uninformative error message, anderror causes panic
by Simon Peyton-Jones 20 Jul '04

20 Jul '04

Tim and I want to tidy up the error-reporting interface in Template Haskell. The goal is that a TH user should be able to control the error messages that appear. Here's a proposal qReport :: Severity -> String -> Q () -- Report an error or warning -- ...but carry on; use 'fail' to stop fail :: String -> Q a -- Part of Monad class qRecover :: (String -> [(Severity,Loc,String)] -> Q a) -> Q a -> Q a -- Recover from the monadic 'fail' -- The first arg is the error handler -- The first String arg to the handler is what was passed to 'fail' qReports :: [(Severity,Loc,String)] -> Q () data Severity = Error | Warning qGetLoc :: Q Loc qGetModule :: Q ModuleName qWithLoc :: Loc -> Q a -> Q a data Loc = Loc FileName LineNumber CharPos The idea is that qReport dumps a message into the monad (but does not print it yet) with an indication of severity. qReport does not cause monadic failure... you can dump in as many error messages as you like. qReport adds location information from the monad to the message. fail causes monadic failure. qRecover recovers from monadic failure, giving to the recovery routine both the string passed to fail, and the accumulated messages from the enclosed computation. It can use qReports to dump all those messages back into the monad -- or it can just discard them if it wants. At a splice point, the typechecker runs the Q computation. If the result is monadic success, it continues with the returned results. If the result is monadic failure, the splice fails too. (That does not result in any panic -- the type checker is designed to fail, and recover at some outer point.) In both cases, the messages from the Q monad are dumped into the typechecker's message pile. One open question. If you say qReport Error "Bad thing" fail "wuggle" in the Q monad, do you get two type error messages ("Bad thing" and "wuggle") or just one? I can think of three possibilities a) fail s is treated as adding an error message with Severity = Error b) fail s adds no error messages c) fail s behaves like (b) if (null s) and like (a) otherwise. The advantage of (b) and (c) is that you can add a whole bunch of error messages, and then fail, without adding yet another. Comments? Once we have an interface agreed, it won't be hard to implement. Simon | -----Original Message----- | From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs- | bounces(a)haskell.org] On Behalf Of Duncan Coutts | Sent: 23 June 2004 01:13 | To: glasgow-haskell-bugs(a)haskell.org | Subject: TH: calling fail in Q monad gives uninformative error message, anderror causes panic | | | ghc makes it's own type checker monad TcM an instance of the Quasi class | (which is rather cunning), however this means that if the user calls the | Monad function 'fail' then the internal TcM fail method gets called. | This monad (IOEnv) was never meant to fail (see | ghc/compiler/utils/IOEnv.hs/) so the error message is: | | Exception when trying to run compile-time code: | Code: genex_count | Exn: user error (IOEnv failure) | | Of course the user code should be using 'report', but if you're using | old code, or code that is generic in the monad it uses then people will | end up calling fail. | | Perhaps the thing to do is to wrap splices in an exception handler and | convert 'fail's into a 'report' instead. | | The same should probably be done for errors raised in pure code by | calling 'error'. At the moment it gives an overly panicky report | (although at least it passes the user's error message through): | | ghc-6.3: panic! (the `impossible' happened, GHC version 6.3): | where clauses & gaurds not yet supprted in function definitions | | The error message there is generated by my code (hence the spelling | errors :-) ). | | Duncan | | _______________________________________________ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

1 0

FW: [ ghc-Bugs-992199 ] Template crash on existential types
by Simon Peyton-Jones 20 Jul '04

20 Jul '04

My previous message was about robust-ifying the conversion from: TH.Syntax -> HsSyn but the other direction has very similar problems. The functions in DsMeta convert: HsSyn -> TH.Syntax Unfortunately, of course TH does not implement all of GHC's extensions, so the desugaring can fall over badly. The right thing to do is presumably to make the desugarer monad support failure and errors, like the type checker monad does, and fail more gracefully. Again, is there anyone who'd be prepared to take this on? Simon -----Original Message----- From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of SourceForge.net Sent: 16 July 2004 10:10 To: noreply(a)sourceforge.net Subject: [ ghc-Bugs-992199 ] Template crash on existential types Bugs item #992199, was opened at 2004-07-16 09:08 Message generated for change (Settings changed) made by mm_aa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=992199&grou p_id=8032 Category: Compiler Group: 6.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Aizatsky (mm_aa) Assigned to: Nobody/Anonymous (nobody) >Summary: Template crash on existential types Initial Comment: Windows XP D:\Tools\ghc>ghc-6.2.1\bin\ghc.exe -fglasgow-exts foo.hs ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1): deSugar/DsMeta.hs:286: Non-exhaustive patterns in function repC module Foo where import Language.Haskell.THSyntax class MyInterface a where foo :: a -> Int data AnyMyInterface = forall a. (MyInterface a) => AnyMyInterface a test = do{ d <- unQ(reifyDecl AnyMyInterface) ; print d } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=992199&grou p_id=8032 _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

1 0

FW: [ ghc-Bugs-992200 ] Template crash on constructing existential datatype
by Simon Peyton-Jones 20 Jul '04

20 Jul '04

Dear Template Haskell folk This SourceForge bug is another example of the bad things that happen when: - a TH program constructs a syntactically invalid program - and then splices it in The trouble is that Convert.convertToHsExpr :: TH.Exp -> LHsExpr RdrName is a pure function, and fails "hard" with a panic, whereas it should really be in the TcM monad, and fail in the way any other type error fails. It's a user error, and should not show up as a panic. Would anyone like to fix hsSyn/Convert.lhs so that it lives in the Tc monad? The call (in TcSplice) is easily changed. It'd probably make sense to move it from hsSyn/ to typecheck/ I'm thinking about putting types in the syntax tree, so if others can help out with tidying up like this, it'd be great. Simon -----Original Message----- From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of SourceForge.net Sent: 16 July 2004 10:11 To: noreply(a)sourceforge.net Subject: [ ghc-Bugs-992200 ] Template crash on constructing existential datatype Bugs item #992200, was opened at 2004-07-16 09:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=992200&grou p_id=8032 Category: Compiler Group: 6.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Aizatsky (mm_aa) Assigned to: Nobody/Anonymous (nobody) Summary: Template crash on constructing existential data type Initial Comment: Windows XP D:\Tools\ghc>ghc-6.2.1\bin\ghc.exe -fglasgow-exts --make foo.hs Chasing modules from: foo.hs Compiling Any ( ./Any.hs, ./Any.o ) Compiling Foo ( foo.hs, foo.o ) Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package haskell-src ... linking ... done. ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1): Malformed predicate module Any where import Language.Haskell.THSyntax genAny :: DecQ -> Q [Dec] genAny decl = do{ d <- decl ; case d of ClassD _ name _ decls -> sequenceQ [genAnyClass (name) decls] _ -> error "genAny can be applied to classes only" } genAnyClass :: String -> [Dec] -> DecQ genAnyClass name decls = do{ returnQ (DataD [forall] anyName [] [constructor] []) } where anyName = "Any" ++ name ++ "1111" constructor = NormalC anyName [(NotStrict, VarT "a")] forall = ForallT [] [] (VarT "a") module Foo where import Any class MyInterface a where foo :: a -> Int foo1 :: Int -> a -> Int $(genAny (reifyDecl MyInterface)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=992200&grou p_id=8032 _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

1 0

RE: [Template-haskell] query functions
by Simon Peyton-Jones 19 Jul '04

19 Jul '04

Hmm. A full check, which involves type classes, requires the function to consult the available instance declarations, so it'd have to be monadic: Type -> Type -> Q Bool Just getting types into the syntax tree at all, which Tim and I now plan to do, is probably a higher priority at the moment; indeed, it may solve the problem you originally wanted typeMatches for. Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Abraham Egnor | Sent: 12 July 2004 18:58 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] query functions | | One bit of functionality I've recently found a need for is various | query functions in TH, i.e. something like | | typeMatches :: Type -> Type -> Bool | | that tests if the second type is a valid specialization of the first | one. The main need I've had for this is to test typeclass membership, | but it would also be useful so that TH code can maintain a mapping of | user-specified types to actions or suchlike. | | Any chance of something like this getting into a future TH revision? | | Abe | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

query functions
by Abraham Egnor 13 Jul '04

13 Jul '04

One bit of functionality I've recently found a need for is various query functions in TH, i.e. something like typeMatches :: Type -> Type -> Bool that tests if the second type is a valid specialization of the first one. The main need I've had for this is to test typeclass membership, but it would also be useful so that TH code can maintain a mapping of user-specified types to actions or suchlike. Any chance of something like this getting into a future TH revision? Abe

1 0

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

23 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 23 Jun '04

23 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 18 Jun '04

18 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