April 2003 - template-haskell

RE: [Template-haskell] unexpected behaviour
by Simon Peyton-Jones 15 Apr '03

15 Apr '03

| -----Original Message----- | out' :: Dec -> () | out' _ = () | | outGen' :: Q [Dec] | outGen' = do d<-reifyDecl Tree | dec1<-clause [pvar "x"] (normal [|out' d|]) [] | return [Fun "out" [dec1]] | | I get an unexpected: | No instance for (Lift Dec) arising from use of `d'... The lifting thing is described (somewhat) in the paper. The idea is that [| out' d |] builds some code (i.e. a data structure) for later execution. That code needs 'd', but d may not be in scope where the code is executed. So the code must include code to build d. That's what lifting does. Yes, Dec could be made liftable, but it's unlikely to be what you want. | Whereas if I replace outGen' by: | | foo :: Q () | foo = do d<-reifyDecl Tree | return (out' d) | | outGen :: Q [Dec] | outGen = do dec1<-clause [pvar "x"] (normal [|foo|]) [] | return [Fun "out" [dec1]] or you could, I think, say | foo :: Q Dec -> Q () | foo qd = do d<-qd | return (out' d) | | outGen :: Q [Dec] | outGen = do let d = reifyDecl Tree | dec1<-clause [pvar "x"] (normal [|foo d|]) [] | return [Fun "out" [dec1]] | Now another thing: after writing some code randomly, I happened to | write foo like this: | | foo :: Q () | foo = do d<-reifyDecl Tree | return $( [| out' d |] ) | | Because I meant that the "out' d" should really be executed _before_. | Now, I understand this was not really sensible (or was it ?). No I don't think so. It should be the case that $[| e |] = e for any e. | However, ghc gives an ugly "panic!" message upon this, which is not | nice, and I suppose had to be reported. Yes, that's a bug, thank you. Simon

1 0

RE: [Template-haskell] instance declarations
by Simon Peyton-Jones 15 Apr '03

15 Apr '03

| More generally, is there some kind of comprehensive up-to-date | documentation for this kind of questions ? Yes indeed: look in libraries/haskell-src/Language/Haskell/THSyntax You can get that from the CVS respository (which is easy to access in read-only mode). Simon

1 0

unexpected behaviour
by François-Régis Sinot 15 Apr '03

15 Apr '03

Hello everybody I am new to the list and intend to bother you a bit in the near future with newbie questions --- my apologies in advance. The following seems strange to me. If I try: data Tree a = Leaf a | Bin (Tree a) (Tree a) out' :: Dec -> () out' _ = () outGen' :: Q [Dec] outGen' = do d<-reifyDecl Tree dec1<-clause [pvar "x"] (normal [|out' d|]) [] return [Fun "out" [dec1]] I get an unexpected: No instance for (Lift Dec) arising from use of `d'... Whereas if I replace outGen' by: foo :: Q () foo = do d<-reifyDecl Tree return (out' d) outGen :: Q [Dec] outGen = do dec1<-clause [pvar "x"] (normal [|foo|]) [] return [Fun "out" [dec1]] Then everything works OK. Is it really a bug or just one of the numerous staging problems ? Shouldn't everything derive Lift, by the way ? (if useful) Now another thing: after writing some code randomly, I happened to write foo like this: foo :: Q () foo = do d<-reifyDecl Tree return $( [| out' d |] ) Because I meant that the "out' d" should really be executed _before_. Now, I understand this was not really sensible (or was it ?). However, ghc gives an ugly "panic!" message upon this, which is not nice, and I suppose had to be reported. Cheers, fr.

1 0

RE: [Template-haskell] Non-typechecked reification brackets
by Simon Peyton-Jones 09 Apr '03

09 Apr '03

I don't fully understand this: - The Piece type uses CondP, ListConsP, whereas your quoted fragments use Cont, (:). I think you are saying that you want to use Haskell syntax to write rewrite rules, which are then munged into real Haskell by your make_rule function. I don't really understand what values are used in the quoted stuff. I'm rather dubious about switching off the type checker for quotations, although I can see that (as you say) it's a pretty non-invasive change. I suggest you discuss this with Oege, work on your examples, see if there are any alternatives, and come back to the TH list if you're still convinced. Simon | -----Original Message----- | From: Ian Lynagh [mailto:igloo@earth.li] | Sent: 08 April 2003 14:26 | To: Simon Peyton-Jones | Cc: template-haskell(a)haskell.org | | On Tue, Apr 08, 2003 at 01:48:24PM +0100, Simon Peyton-Jones wrote: | > I didn't understand this. Care to elaborate, with some examples? | | OK, the key point is that it is easier, should you want to build an | expression that doesn't type check, to have GHC do it for you than to | write App (Con "Tup") (...) by hand. | | In this particular case (which is a reimplementation of pan) I have | (I've cut this down a lot): | | data Piece = | -- Exp | AppP Addr Addr | | CondP Addr Addr Addr | | TupP Addr | -- DotDot | | FromP Addr | -- [a] | | ListConsP Addr Addr | | ListNilP | | which I can use to represent the syntax trees as DAGs with a FiniteMap | in each direction (Piece -> Addr, Addr -> Piece). | | Something I want to be able to do is to float ifs up as then I can | simplify more, e.g., | 1 + (if g then 2 else 3) | to | if g then 3 else 4 | | So I have a function make_opt_rule :: Exp -> Exp so, for example: | | ======================= | do rule <- runQ [| \g x y z -> App x (Cond g y z) | --> | Cond g (App x y) (App x z) |] | putStrLn $ render $ pprExp $ make_opt_rule rule | ======================= | | produces: | | ======================= | \p -> case p of | AppP x'1 aopt@1 ->i | do popt@1 <- look_at aopt@1 | case popt@1 of | CondP g'0 y'2 z'3 -> | do addr@0 <- local_opt (AppP x'1 y'2) | addr@1 <- local_opt (AppP x'1 z'3) | addr@2 <- local_opt (CondP g'0 addr@0 addr@1) | return (Just addr@2) | _ -> return Nothing | _ -> return Nothing | ======================= | | Now, this one is fine because both sides of the rule correspond to valid | Haskell expressions. But I also want to rewrite | (0, if g then 1 else 2, 3) | to | if g then (0, 1, 3) else (0, 2, 3) | | Now, as it turns out it is fine to do locally bad rewrites like | | [| \g x y z -> (:) (Cond g x y) z --> Cond g ((:) x z) ((:) y z) |n], | [| \g x y z -> (:) x (Cond g y z) --> Cond g ((:) x y) ((:) x z) |n], | | (which moves the Cond up through the list of expressions wrapped by Tup) | as when it gets to the top it will be rewritten again with | | [| \g x y -> Tup (Cond g x y) --> Cond g (Tup x) (Tup y) |n], | | and we are back with a valid datastructure represented by the DAG. | Turning off type checking allows me to tell GHC that I know that what I | am doing looks bad, but if it looks the other way for a minute it'll all | turn out OK in the end (both in terms of the code spliced in (which | operates on Pieces) and the DAG that will ultimately be flattened). | | | Did that make sense? | | | Thanks | Ian |

1 0

RE: ghc-5.05 / template haskell bug
by Simon Peyton-Jones 08 Apr '03

08 Apr '03

Thomas Absolutely right! There is a total omission in the TH implementation for the free 'x' in \x -> $(power 2 [| x |]) You can get round this in a clunky way by wrapping the whole thing in $[| |], thus $([| \x -> $(power 2 [| x |]) |]) This works, but it's not pretty. The Right Thing is to fix it, which I hope to do. thanks for pointing this out. TH is pretty subtle Simon | -----Original Message----- | From: Thomas Harke [mailto:harke@cse.ogi.edu] | Sent: 10 March 2003 18:15 | To: glasgow-haskell-bugs(a)haskell.org | | Hi, | | while experimenting with template haskell I encountered the following: | | ] ghc --make Main.hs | ] Chasing modules from: Main.hs | ] Skipping Power ( Power.hs, ./Power.o ) | ] Compiling Main ( Main.hs, ./Main.o ) | ] ghc-5.05: panic! (the `impossible' happened, GHC version 5.05): | ] nameModule x {- v a1fV -} | ] | ] Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, | ] or http://sourceforge.net/projects/ghc/. | ] | ] | ] make: *** [main] Error 1 | | This was using a version very recently checked out of CVS (Friday, 14 March) | | The files that caused the problem are attached. | | -- | Tom Harke | Computer Science and Engineering Department | Oregon Graduate Institute | | Weiler's Law: | Nothing is impossible for the man who doesn't have to do it himself

1 0

RE: [Template-haskell] Non-typechecked reification brackets
by Simon Peyton-Jones 08 Apr '03

08 Apr '03

I didn't understand this. Care to elaborate, with some examples? S | -----Original Message----- | From: template-haskell-admin(a)haskell.org [mailto:template-haskell- | admin(a)haskell.org] On Behalf Of Ian Lynagh | Sent: 08 April 2003 12:45 | To: template-haskell(a)haskell.org | | | Hi all, | | I've just (locally) added a [| ... |n] style of reification brackets | that aren't type checked. This means I can do things like | | [| \g x y -> Tup (Cond g x y) --> Cond g (Tup x) (Tup y) |n] | | for describing rewrite rules (they end up being correctly typed when | I've fiddled about with them). I think I've worked around cases where | I'd wanted to do this but couldn't in the past, but where I had a | simpler alternative; I didn't keep a note of them unfortunately. This | has a very small impact on the code - just add a Bool to ExpBr (and the | others) "data HsBracket id = ExpBr (HsExpr id) Bool" and then alter the | handful of places it's used. | | My question is, is this an appropriate thing to be in Template Haskell? | I for one would find it useful. | | | Thanks | Ian | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1

Release
by Ian Lynagh 08 Apr '03

08 Apr '03

As I understand it the GHC team are heading towards a release including TH in the not too distant future. I think it would be good if the biggest outstanding issues could be fixed before then (and indeed, just fixed ASAP). The one that causes me the most hoop jumping is the type parameters to some of the TH datastructures. For example, I have some code like this: class ToDec a where to_dec :: a -> Dec instance ToDec Dec where to_dec = id class ToExp a where to_exp :: a -> Exp instance ToExp Exp where to_exp = id instance (ToExp e, ToDec d) => Foo (Match p e d) where foo (Mat p (Normal e) ds) = bar (Normal (Let (map to_dec ds) (to_exp e))) Which I'd much rather be able to write as instance Foo Match where foo (Mat p (Normal e) ds) = bar (Normal (Let (map to_dec ds) (to_exp e))) Previous discussions about this have all petered out before reaching a conclusion, but I haven't seen anyone actually stand up and defend the parameterised types, and it's hard to see how they could be useful without everything being parameterised anyway. Can we get rid of them? Please? Or at least have an explanation of why not... Hmmm, or maybe I should be asking for them to be extended to cover all the types to make it easier to have a type of reification that annotates the tree with type and strictness information. I'd still have the problem above, but at least more things would be possible. Anyway, I'm confused, but sitting in the middle is just driving me mad! Thanks Ian

1 0

Non-typechecked reification brackets
by Ian Lynagh 08 Apr '03

08 Apr '03

Hi all, I've just (locally) added a [| ... |n] style of reification brackets that aren't type checked. This means I can do things like [| \g x y -> Tup (Cond g x y) --> Cond g (Tup x) (Tup y) |n] for describing rewrite rules (they end up being correctly typed when I've fiddled about with them). I think I've worked around cases where I'd wanted to do this but couldn't in the past, but where I had a simpler alternative; I didn't keep a note of them unfortunately. This has a very small impact on the code - just add a Bool to ExpBr (and the others) "data HsBracket id = ExpBr (HsExpr id) Bool" and then alter the handful of places it's used. My question is, is this an appropriate thing to be in Template Haskell? I for one would find it useful. Thanks Ian

1 0