Simon Peyton-Jones wrote:
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.
This is annoying - but I don't think its a show stopper for any project I have attempted - although most of the things I have looked at have tended to be language extentions, so they are naturally defined in one file and used in lots of others. In an ideal world I would like to be able to define splices in the same file, and have them look like Haskell keywords (no '$').
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.
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"? In Ian's example if 'foo' was the result of an earlier splice in the same file? Keean