- template-haskell - Haskell.org

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 09 Apr '03

09 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

Re: [Template-haskell] Template Haskell bug
by Derek Elkins 19 Mar '03

19 Mar '03

First, temporary stop-gap measure: Just strip that symbol from HSbase_cbits.o and hopefully you don't need it. I've experienced something similar on Cygwin. There are four symbols undefined that causes the exact same error (only with different symbols, one is, for example, __imp___pctype). WARNING! The rest is under-educated rampant speculation, take a shaker of salt with this grain of thought. I imagine the problem has to do with differing libraries linked in when compiling as compared to interpreting. Either different libraries needed to make an exe (my symbols seem related to importing definitions from mscrt in MinGW) or "different" RTS's (your symbol looks like GMP stuff). As I don't imagine GHCi is broken this blatantly in 5.05 (though try it and see) and it would seem sensible for TH to use some of GHCi code, my suspicion is the problem is in setup/interface code in TH for/to GHCi. Unless, of course, GHCi is broken, then almost certainly that's the problem. Or perhaps simply, the symbols just shouldn't be there. Well, hopefully, you get a coherent response from someone in the know. In the meantime, hopefully you'll make some work-around or my stop-gap solution works for you. I'm not too gung-ho into looking into it myself; the stop-gap solution works beautifully for me, and I can live with my program exploding into glittery pieces if I use the wrong function (or more likely simply not linking), since I doubt I'll ever use the ones related to the "undefined" symbols I've stripped. >From: Sean Seefried <sseefried(a)cse.unsw.EDU.AU> >To: template-haskell(a)haskell.org >Subject: [Template-haskell] Template Haskell bug >Date: Sat, 15 Mar 2003 19:33:27 +1100 (EST) > >With GHC HEAD as of 14/03/2003 I get the following error when I try to >compile: > >This was done on Debian Linux kernel version 2.4.20 > >main = putStrLn (show ($([| 20 |]))) > >--------------- > >/home/sseefried/local/lib/ghc-5.05/HSbase_cbits.o: unknown symbol >`__umoddi3' >Loading package base ... linking ... ghc-5.05: panic! (the `impossible' >happened, GHC version 5.05): > can't load package `base' > >Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, >or http://sourceforge.net/projects/ghc/. > >--------------- > >Any idea why? > >Sean Seefried >_______________________________________________ >template-haskell mailing list >template-haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/template-haskell _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1

Template Haskell bug
by Sean Seefried 15 Mar '03

15 Mar '03

With GHC HEAD as of 14/03/2003 I get the following error when I try to compile: This was done on Debian Linux kernel version 2.4.20 main = putStrLn (show ($([| 20 |]))) --------------- /home/sseefried/local/lib/ghc-5.05/HSbase_cbits.o: unknown symbol `__umoddi3' Loading package base ... linking ... ghc-5.05: panic! (the `impossible' happened, GHC version 5.05): can't load package `base' Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. --------------- Any idea why? Sean Seefried

1 0

RE: ghc-5.05 / template haskell bug
by Simon Peyton-Jones 12 Mar '03

12 Mar '03

Urkle I'm about to take off to Redmond for a week. Not sure when I'll get to this, but I hope I'll manage it sometime soon. I hope it's not a showstopper for you. (You might want to join the template-haskell mailing list) simon | -----Original Message----- | From: Thomas Harke [mailto:harke@cse.ogi.edu] | Sent: 10 March 2003 18:15 | To: glasgow-haskell-bugs(a)haskell.org | Subject: ghc-5.05 / template haskell bug | | 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] Instance declarations
by Derek Elkins 20 Feb '03

20 Feb '03

Sorry about that. It looks like it was my fault. I made a list of functions rather than a list of clauses. >From: "Simon Peyton-Jones" <simonpj(a)microsoft.com> >To: "Derek Elkins" <ddarius86(a)hotmail.com>,<template-haskell(a)haskell.org> >Subject: RE: [Template-haskell] Instance declarations >Date: Wed, 19 Feb 2003 15:21:54 -0000 > >Can you give the actual source code for the offending program, please? > >Simon > >| -----Original Message----- >| From: Derek Elkins [mailto:ddarius86@hotmail.com] >| Sent: 13 February 2003 20:29 >| To: template-haskell(a)haskell.org >| Subject: [Template-haskell] Instance declarations >| >| My first email seems to have gotten lost, if it meanders it's way >here, then >| sorry for the repeat. >| >| Anyways, generating a set of pattern matching functions in an instance >| declaration (maybe in general, though I haven't tested it) causes a >| "conflicting definitions error". Rewriting as a case expression is >one >| work-around. >| >| E.g. >| >| instance (NFData a) => NFData (Tree a) where >| rnf (Leaf a) = rnf a >| rnf (Branch a b) = rnf a `seq` rnf b >| >| doesn't work, but rewriting as >| >| instance (NFData a) => NFData (Tree a) where >| rnf x = case x of >| (Leaf a) -> rnf a >| (Branch a b) -> rnf a `seq` rnf b >| >| does. >| >| I suspect that it may have to do with the generated code being >considered at >| a lower level (i.e. the transformation of the above into the below is >| already considered done). It may just be I'm creating the functions >| incorrectly, so if you can't get the error to happen I can provide the >code >| I'm using. >| >| Separately: I've written a variety of fold algebras over data >declarations. >| I'm not sure how useful they'll be, but if you're interested email me, >and >| I'll email the source. I haven't tested them, but it's pretty >mechanical >| code so I don't suspect any major problems and any should be >relatively >| straightforward to fix. See `Dealing with Large Bananas` for the >concept >| (and for documentation, as it has no documentation yet). >| >| _________________________________________________________________ >| STOP MORE SPAM with the new MSN 8 and get 2 months FREE* >| http://join.msn.com/?page=features/junkmail >| >| _______________________________________________ >| template-haskell mailing list >| template-haskell(a)haskell.org >| http://www.haskell.org/mailman/listinfo/template-haskell >_______________________________________________ >template-haskell mailing list >template-haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/template-haskell _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

RE: [Template-haskell] RE: Declaration reordering
by Simon Peyton-Jones 20 Feb '03

20 Feb '03

| I've had a quick look and I think something called by one or both of | "tcMonoExpr (HsBracket brack loc) aes_ty" and "tcBracket"? Oh, but the | former calls the latter, so probably somewhere in tcTopSrcDecls? I'll | try following this through if so. deSugar/DsMeta.lhs, line 156 or thereabouts, is where a declaration bracket gets turned into data structure. Instead of return (val_ds ++ catMaybes tycl_ds ++ inst_ds) you want return (sortByLoc (...the same thing...)) where sortByLoc does the sorting by source location. Have fun! Actually it should be really easy. Simon

1 0