October 2004 - template-haskell

FW: [Template-haskell] RE: calling fail in Q monad gives uninformativeerror message, anderror causes panic
by Simon Peyton-Jones 05 Dec '04

05 Dec '04

Dear Template Haskell colleagues I sent three messages to the TH list a month ago. Here's one of them: the others concerned the conversions TH.Syntax <-> HsSyn; I'll fwd them in the next two messages I didn't get a single reply to any of the three. Either the TH mailing list is broken, or else you are all busy with other stuff. (After all, all three did ask for volunteers, in one form or another.) Does anyone care? I'm busy implementing GADTs at the moment, so TH has a somewhat back seat. It'll probably stay that way unless there are some signs of life in the TH ranks. Simon -----Original Message----- From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On Behalf Of Simon Peyton-Jones Sent: 20 July 2004 12:19 To: Duncan Coutts; Template Haskell List Subject: [Template-haskell] RE: calling fail in Q monad gives uninformativeerror message, anderror causes panic 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 _______________________________________________ template-haskell mailing list template-haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/template-haskell

3 3

RE: TH2 bug
by Simon Peyton-Jones 03 Nov '04

03 Nov '04

OK, now I get it. I'm copying the TH list in the hope that other TH aficionados will chime in. The problem is with reify, not the '' notation. Here it is in a nutshell: what value should be returned by the call (reify ''(->) )? Recall that reify :: Name -> Q Info So reify claims to return an Info, and for a type constructor it currently returns a TyConI; but a TyConI contains a Dec, and there simply is no Dec in the TH syntax for a function type; it's built in, rather like Int# etc. So reify falls over in a bad way. It's obviously unsatisfactory for reify to just fall over in this case, but what would you like? A new constructor in Info for primitive tycons? A new constructor in Dec? And what questions do you want to be able to ask of the value in the Info? For example would it be enough to day data Info = TyConI Dec | PrimTyCon | ClassI Dec ...etc... where the PrimTyCon is returned for (->), Int#, etc? Nothing difficult about fixing this once the design is clear. Simon | -----Original Message----- | From: Keean Schupke [mailto:k.schupke@imperial.ac.uk] | Sent: 27 October 2004 11:14 | To: Simon Peyton-Jones | Subject: Re: TH2 bug | | Yup, using HEAD. Here's an example template: | | ttypeshow :: Name -> Q [Dec] | ttypeshow q = do | r <- reify q | case r of | (TyConI t) -> runIO . putStrLn . show $ t | _ -> return () | return [] | | Then in another file we do: | | $(ttypeshow ''(->)) | | Which fails, as does ''(), and ''(,) etc... | | ''[] works okay however | | Keean. | | | Simon Peyton-Jones wrote: | | >I can't reproduce this. Works for me. What version of GHC are you | >using? The HEAD I assume? | > | >Simon | > | >| -----Original Message----- | >| From: MR K P SCHUPKE [mailto:k.schupke@imperial.ac.uk] | >| Sent: 22 October 2004 18:23 | >| To: glasgow-haskell-users(a)haskell.org; Simon Peyton-Jones | >| Subject: TH2 bug | >| | >| | >| Just reporting a bug, taking types using '' works fine for: | >| | >| ''Int | >| ''[] | >| | >| But when you try: | >| | >| ''(->) | >| | >| you get: | >| | >| No match in record selector TyCon.algTcRhs | >| | >| Please report it as a compiler bug to | >glasgow-haskell-bugs(a)haskell.org, | >| or http://sourceforge.net/projects/ghc/. | >| | >| | >| Keean. | > | >

3 3

template haskell (reify bug and existentials)
by Keean Schupke 03 Nov '04

03 Nov '04

Re: my two earlier postings: 1) existentials in data declarations. I have a project which needs this, Simon PJ thought it was fairly easy to put in and suggested that Ian Lynagh might implement it. Do I need to persuade people further? Will it get done now? Some feedback as to whether it might get done would be nice... Just to clarify I want to do: $(something [d| data A = forall a . A a |] 2) reification of functions (and other primitives)... want to do something like: reify ''(->) Fails because reify/Info does not support reifying primitives. There is already support in the Type type for primitive types (-> (,,) []) so the obvious way to add this is to alter Info to: data Info = ClassI Dec | ClassOpI Name Type Name Fixity | TyConI Dec | PrimTyConI Type | DataConI ... So what are the chances of getting these changes implemented. I need them for a current project, and would appreciate it if someone who knows the inner workings of template-haskell could implement the changes in the CVS HEAD branch of GHC. Failing that I am prepared to have a go myself, but I want to make sure that nobody else is likely to do it first.

2 4

RE: [Template-haskell] Dyamic scoping question
by Simon Peyton-Jones 01 Nov '04

01 Nov '04

Here's your program boiled down a bit foo = 3 baz = $(varE ("fo" ++ "o")) Like any Haskell compiler, GHC does dependency analysis, and type-checks in that order. There no way for it to see that 'baz' depends on 'foo', so it may well typecheck the definition of baz before that of foo. I haven't actually run your example, but I bet that's what's happening. "-ddump-rn" would tell you, because it shows the code after dependency analysis. I wonder if others have tripped over this. There is a tension between dynamic scope and dependency analysis (which is required for type checking) that's hard to resolve. For example, you probably want the example to work even if the definition of 'foo' is after that of 'baz'; at least that's the standard Haskell story. I suppose a workaround is to put 'foo' in another module, but it's not nice. Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Bryn Keller | Sent: 25 October 2004 19:48 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] Dyamic scoping question | | Hi folks, | | I'm trying to use TH to generate parsers and writers for arbitrary | datatypes. In the end I'd like every part of the declaration and | generation of these functions to be automatic, but at this early stage | I'm just trying to get one aspect of all that to work. So at the moment, | all I want is to generate a function that exercises a parsing | computation I've already defined earlier in the module: | | import Text.ParserCombinators.Parsec | | import Splices | | data SomeType = S Int | | sometype_p = do {string "S"; num <- many1 digit; return $ S (read num)} | | readSomeType = $(reifyDecl SomeType >>= mkLineReader) | | | and in Splices.hs: | | module Splices where | | import Language.Haskell.THSyntax | import Text.ParserCombinators.Parsec (parse) | import Data.Char (toLower) | | modifyName f name = concat [modules, ":", f origName] | where | (modules, (_:origName)) = break (==':') name | | lower = map toLower | | mkLineReader :: Dec -> Q Exp | mkLineReader (DataD _ name _ fields _) = do | let parserName = varE $ modifyName ((++"_p").lower) name | [| | \line -> case parse $(parserName) line line of | Left err -> error (show err) | Right val -> val | |] | | Now, when I try to compile this I get a message like so: | | tcLookup: `sometype_p' is not in scope | In the first argument of `parse', namely `sometype_p' | In the scrutinee of a case expression: | parse sometype_p line'0 line'0 | In the case expression: | case parse sometype_p line'0 line'0 of | Left err'1 -> error (show err'1) | Right val'2 -> val'2 | | When I add -ddump-splices, it prints this in addition: | | \ line'0 | -> case | Text.ParserCombinators.Parsec.Prim.parse Main.sometype_p | line'0 | line'0 | of | Data.Either.Left err'1 -> GHC.Err.error (GHC.Show.show err'1) | Data.Either.Right val'2 -> val'2 | | which tells me that the name sometype_p is getting built correctly, but | it's just not finding the sometype_p that I've already defined. I | thought that varE was the way to capture existing variables of this sort | in Template Haskell, was I mistaken? What is the approved way? Or have I | just missed something crucial? | | Thanks, | | Bryn | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1

RE: [Template-haskell] Existentials
by Simon Peyton-Jones 27 Oct '04

27 Oct '04

It's not hard, no. Ian Lynagh is usually kind enough to do the honours! Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Keean Schupke | Sent: 26 October 2004 11:19 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] Existentials | | Hi, any chance of support for existential datatypes in | template-haskell... It currently supports local universal | quantification: | | data A = A (forall a . a) | | but not existental: | | data A = forall a . A a | | Is this hard to add? It would be really useful to me if TH | did support existentials... | | Regards, | Keean. | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

RE: [Template-haskell] Pattern reification in Template Haskell
by Simon Peyton-Jones 26 Oct '04

26 Oct '04

Yes, I'm afraid that pattern quotations and splices are very much not implemented. There's a whole raft of design questions which we sort-of answer in that design note, but not terribly satisfactorily. I do have a bunch of things on my TH to-do list. Pattern splices aren't at the top of it, in fact, but name-splicing -- the ability to splice a name in a binding position -- would be very useful. But there was so little reaction to my last few messages to this list that TH has slipped down my priority list. (Currently I'm busy with GADTs.) I'm not sure whether the quietness of the TH list is because (a) TH works so well that there's no need to say anything or (b) no one is using it. Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Sean Seefried | Sent: 20 October 2004 02:02 | To: Template Haskell Mailing List | Subject: [Template-haskell] Pattern reification in Template Haskell | | Hi all, | | Just a quick question about pattern reification. | | In Tim Sheard and Simon Peyton Jones' notes on Template Haskell paper | we are told that the following declaration would be valid: | | p1 = [p| (x,y) |] | | And that this is literally equivalent to: | | return (Ptuple [Pvar (mkBndr "x"), Pvar (mkBndr "y")]) | | But when I try it I get told that x and y are not in scope. But isn't | that precisely the point? I'm introducing new scope. | I realise there is still some development to be done on Template | Haskell and I was wondering whether this was just one of the things | still on the todo list or whether I was doing something wrong. | | Cheers, | | Sean | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

3 4

Existentials
by Keean Schupke 26 Oct '04

26 Oct '04

Hi, any chance of support for existential datatypes in template-haskell... It currently supports local universal quantification: data A = A (forall a . a) but not existental: data A = forall a . A a Is this hard to add? It would be really useful to me if TH did support existentials... Regards, Keean.

1 0

Dyamic scoping question
by Bryn Keller 25 Oct '04

25 Oct '04

Hi folks, I'm trying to use TH to generate parsers and writers for arbitrary datatypes. In the end I'd like every part of the declaration and generation of these functions to be automatic, but at this early stage I'm just trying to get one aspect of all that to work. So at the moment, all I want is to generate a function that exercises a parsing computation I've already defined earlier in the module: import Text.ParserCombinators.Parsec import Splices data SomeType = S Int sometype_p = do {string "S"; num <- many1 digit; return $ S (read num)} readSomeType = $(reifyDecl SomeType >>= mkLineReader) and in Splices.hs: module Splices where import Language.Haskell.THSyntax import Text.ParserCombinators.Parsec (parse) import Data.Char (toLower) modifyName f name = concat [modules, ":", f origName] where (modules, (_:origName)) = break (==':') name lower = map toLower mkLineReader :: Dec -> Q Exp mkLineReader (DataD _ name _ fields _) = do let parserName = varE $ modifyName ((++"_p").lower) name [| \line -> case parse $(parserName) line line of Left err -> error (show err) Right val -> val |] Now, when I try to compile this I get a message like so: tcLookup: `sometype_p' is not in scope In the first argument of `parse', namely `sometype_p' In the scrutinee of a case expression: parse sometype_p line'0 line'0 In the case expression: case parse sometype_p line'0 line'0 of Left err'1 -> error (show err'1) Right val'2 -> val'2 When I add -ddump-splices, it prints this in addition: \ line'0 -> case Text.ParserCombinators.Parsec.Prim.parse Main.sometype_p line'0 line'0 of Data.Either.Left err'1 -> GHC.Err.error (GHC.Show.show err'1) Data.Either.Right val'2 -> val'2 which tells me that the name sometype_p is getting built correctly, but it's just not finding the sometype_p that I've already defined. I thought that varE was the way to capture existing variables of this sort in Template Haskell, was I mistaken? What is the approved way? Or have I just missed something crucial? Thanks, Bryn

1 0

Pattern reification in Template Haskell
by Sean Seefried 20 Oct '04

20 Oct '04

Hi all, Just a quick question about pattern reification. In Tim Sheard and Simon Peyton Jones' notes on Template Haskell paper we are told that the following declaration would be valid: p1 = [p| (x,y) |] And that this is literally equivalent to: return (Ptuple [Pvar (mkBndr "x"), Pvar (mkBndr "y")]) But when I try it I get told that x and y are not in scope. But isn't that precisely the point? I'm introducing new scope. I realise there is still some development to be done on Template Haskell and I was wondering whether this was just one of the things still on the todo list or whether I was doing something wrong. Cheers, Sean

1 0