Re: FW: TH restrictions

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