July 2004 - template-haskell

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

21 Jul '04

| While on the topic of TH, let me float "yet another idea"TM | Include {-# #-} pragmas in the TH abstract syntax. | | Why? Because it would allow domain/library-specific hints and | annotations. | | data Pragma = PragmaGhcRule ... | PragmaGhcSpecialise ... | PragmaOther String --free form | | My application of this might be to let the user indicate binding times | when doing partial evaluation, eg: | | {-# BT foo :: Static -> Dynamic -> Dynamic #-} | foo :: Int -> Int -> int | foo x y = ... Reasonable idea. I'll put it in the list, but if anyone wants to have a go at implementing it, go right ahead. Simon

1 0

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

20 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 19 Jul '04

19 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 19 Jul '04

19 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 12 Jul '04

12 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