November 2004 - template-haskell

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

04 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: [Template-haskell] Bug? Unique class names...
by Simon Peyton-Jones 26 Nov '04

26 Nov '04

It's all part of this newName stuff I wrote about. I hope to have it done in a week or so | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Keean Schupke | Sent: 26 November 2004 11:09 | To: Ian Lynagh | Cc: template-haskell(a)haskell.org; Simon Peyton-Jones | Subject: [Template-haskell] Bug? Unique class names... | | Hi, | I am trying to generate classes on the fly... as classes may get | generated more | than once, I want guaranteed unique names (sounds like a job for newName)... | However, whilst the first example works, the second fails: | | >-- this works | >test :: Q [Dec] | >test = do | > k <- newName "k" | > c <- classD (cxt []) (mkName "MyClass") [k] [] [] | > return [c] | | >-- this fails | >test :: Q [Dec] | >test = do | > n <- newName "MyClass" | > k <- newName "k" | > c <- classD (cxt []) n [k] [] [] | > return [c] | | In the second case this error is given: | | ghc-6.3: panic! (the `impossible' happened, GHC version 6.3): | nameModule MyClass{tc a3dX} | | Is this a bug? How easy is it to fix? | | Regards, | Keean. | | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1

Binding again
by Simon Peyton-Jones 26 Nov '04

26 Nov '04

In looking into my TH bug stack, I've found the following question. Suppose we have d1 :: Q [Dec] d1 = return [FunD (mkName "f") ...] d2 :: Q [Dec] d2 = do { fn <- newName "f"; return [FunD fn ...] } QUESTION 1: is this OK: $d1 h = f 3 QUESTION 2: What about this? $d2 h = f 3 The answer to Q1 must presumably be 'yes', but what about Q2. "newName" generates a fresh name, to be sure, but does it bind the 'f' in the subsequent declaration. I think the answer is probably 'yes'. COnsier [| \x -> f $(dyn "x") |] Here I think we all agree the $(dyn "x") picks up the binding for 'x', even though the binding must be generated with newName. And (returning to Q2), the "top-level splice hack" treats everything following the top-level splice as if it were (dyn "f") stuff. But a 'yes' to Q2 might be considered inconvenient, because you might generate lots of (newName "f"), and they'd then clash. Views? Simon

4 4

RE: FW: [Template-haskell] TH restrictions
by Simon Peyton-Jones 25 Nov '04

25 Nov '04

| >| foo = and | >| bar = [| foo |] | >| | >| in one module used to be OK whereas now it gives | >| | >| No instance for (Language.Haskell.TH.Syntax.Lift ([Bool] -> Bool)) | > I have just fixed this. Kean asked: | I came accross this one and thought it was a feature. If this could be | fixed it would actually have more impact... one question though, what | happens if: | | [d| dec 1 |] | [d| dec 2 |] | | We refer to some thing spliced in "dec 1" inside the quasi-quotes of | "dec 2"? You'll have to give a more precise example. In my example, the occurrence of 'foo' referred to a lexically-visible binding for foo. You might need $(dyn "foo") in your example. However, you can say $(furgle ...) x = [| foo |] where furgle returns a binding for foo, say [d| foo = and |]; that should work fine. Simon

2 1

local type declarations
by Einar Karttunen 24 Nov '04

24 Nov '04

Hello Is it possible to create local types with template Haskell? I would like to create a metafunction like: withMod :: IVal a => Int -> (MInt a -> MInt a) -> Int -> Int withMod modulus func param = do create a new type T create instance IVal T where val _ = modulus [| unM $ func (param :: MInt T) |] This is trying to conquer the limitation of no local class instances. Can this be done with TH without resorting to tricks like generating auxiliary files? Here is the context leading to withMod: -- short modular arithmetic class IVal a where val :: a -> Int newtype MInt a = MInt Int deriving (Eq,Show) unM (MInt v) = v instance IVal a => Num (MInt a) where (MInt a) + (MInt b) = MInt $ (a + b) `mod` val (undefined :: a) (MInt a) - (MInt b) = MInt $ (a - b) `mod` val (undefined :: a) (MInt a) * (MInt b) = MInt $ (a * b) `mod` val (undefined :: a) abs _ = error "MInt abs not supported" signum _ = error "MInt signum not supported" fromInteger i = MInt (fromEnum i) example :: IVal a => MInt a -> MInt a example a = a + a -- expression => spliced to => runtime -- withMod 4 example 3 => unM $ func (3 :: MInt T_xyz) => 2 ps. I have read the configurations paper which used to encode the value with the typesystem, but am trying to look for a cleaner way. - Einar Karttunen

1 0

RE: [Template-haskell] panic: addImpDecls
by Simon Peyton-Jones 23 Nov '04

23 Nov '04

Strange. GHC just doesn't allow nested declaration splices -- and gives a horrible message to boot. I'm not sure why I hadn't even registered that point. Turns out that the way to fix this is closely connected with preparatory work towards producing *typed* TH syntax trees. TH has grown quite a long to-do list in the last month. I'll try to do something about it before our Xmas release of 6.4. How urgent is this particular thing for you? Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Ian Lynagh | Sent: 21 November 2004 23:59 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] panic: addImpDecls | | | Hi all, | | If I have | | module Q () where | | $( [d| | $( [d| foo = 'c' |] ) | |] | ) | | or even | | module Q () where | | $( [d| | $( [] ) | |] | ) | | then "ghc -fth --make Q.hs" gives me: | | ghc-6.3: panic! (the `impossible' happened, GHC version 6.3): | addImpDecls | | | Thanks | Ian | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1

RE: [Template-haskell] panic: addImpDecls
by Simon Peyton-Jones 23 Nov '04

23 Nov '04

| Is this preparatory work visible at all? Or still under wraps? Could | you explain the idea in a little more detail? Is this only for "closed" | declarations and expressions? It's not secret; it's just not implemented! Briefly the deal is this. Currently the type checker typechecks brackets, but throws the translated (type-annotated) term away. The desugarer translates the original un-annotated term. It'd be better to keep the translated term, so the desugarer could (if THSyntax supported types somehow) have access to the types. But the translated term is slightly mixed up: there are type abstractions and applications (easy to discard), but AbsBinds (the translation of a binding group) is a bit more of a problem. Anyway, it seems like the right way to go. Just need to find time to do it. Simon

1 0

panic: addImpDecls
by Ian Lynagh 21 Nov '04

21 Nov '04

Hi all, If I have module Q () where $( [d| $( [d| foo = 'c' |] ) |] ) or even module Q () where $( [d| $( [] ) |] ) then "ghc -fth --make Q.hs" gives me: ghc-6.3: panic! (the `impossible' happened, GHC version 6.3): addImpDecls Thanks Ian

1 0

RE: FW: [Template-haskell] TH restrictions
by Simon Peyton-Jones 19 Nov '04

19 Nov '04

| > 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. | | For what it's worth, I think one of the biggest irritations I've had | with writing stuff using TH is the need to split things across module | boundaries. This often leads to things that should logically be in the | same module being split I agree with this; I'd like to know how much it affects other people too. It's tricky to implement, though. I don't really want to compile each definition to byte code as we encounter it, just in case the next definition contains a splice. (That would slow down every single compilation, whether or not it used TH.) I guess I could look ahead to see if there was a splice in the next definition group, and if so compile the entire module up to that point. Even that isn't usually necessary, because the splice may not call anything defined earlier. Perhaps one could compute the transitive closure of things needed. So it'd be real work. What do others think? | Also, I think this has got worse at some point. Going back over some of | my old code it looks like this sort of thing: | | foo = and | bar = [| foo |] | | in one module used to be OK whereas now it gives | | No instance for (Language.Haskell.TH.Syntax.Lift ([Bool] -> Bool)) This looks like a bug -- I'll try to fix it. Simon

2 1

Multi-stage programming examples
by Ian Lynagh 17 Nov '04

17 Nov '04

Hi all, I have ported a few small multi-state programming examples from MetaOCaml and put them at: http://www.haskell.org/th/examples/msp_ex.tar.gz Thanks Ian

1 0