[Template-haskell] RE: Partial evaluation using TH

[Ian Lynagh]

On Wed, Dec 31, 2003 at 05:54:08PM -0000, Simon Peyton-Jones wrote:
> 
> Nested brackets
> ~~~~~~~~~~
> 
> | > evalProg' = [| evalProg |]		--same evalProg as before
> | 
> | > compileProg :: ExpQ -> ExpQ
> | > compileProg = $( cogen [| evalProg' |] )
> 
> I'm very keen that TH should obey the beta rule.  That is, given
> 	x = e
> you can always replace x by e.  So in this case you ought to be able to
> write
> 
> 	compileProg = $(cogen [| [| evalProg |] |])

OK, but if I have something like

$(
    do e <- [| evalProg' |]
       do_something e
 )

then I would expect do_something to be given a (VarE n) for some name n.
It doesn't make sense for the compiler to be able to apply the beta rule
in this case.


Are you thinking [| [| 5 |] |] would be equivlent to
return $ return $ LitE $ intL 5    or
return $ QuoteE $ LitE $ intL 5    (data Exp = ... | QuotedE Exp)
?

> ===> Conclusion 1: TH should allow nested brackets (and presumably
> nested $'s).

I think these have to be run innermost first.


There is the meaning of things like

    f x = [| [| $x |] |]
    g x = $(f 5)

to consider too. I think what makes most sense here depends on which
choice for nested quasi-quotes means above is chosen. For the first I
think g has to be equivalent to
    g x = [| [| 5 |] |]
Although neither alternative is unreasonable if we take the second
alternative, I think
    g x = [| $x |]
makes more sense (as if I looked at the value of [| [| $x |] |] I would
expect to see (Splice some-name-for-x) in the middle). Maybe if we took
this path then there should be a way to escape $s, giving the choice to
the programmer. Say "f = [| [| \$x |] |]" would give "g x = [| $x |]" but
"f = [| [| $x |] |]" would give "g x = [| [| 5 |] |]" (with an extra \
for each layer of quotes).

> Double encoding
> ~~~~~~~~~~
> You ask for a function 
> 	enc :: Exp t -> Exp (Exp t)
> 
> Well that's easy, isn't it?
> 
> 	enc x = return x
> 
> I'm not sure if that's what you want.  Indeed, you say " So, the thing
> that concerns me is the double encoding. I can't intuitively see the
> need for it..."  Maybe you can give the intuition for why you can't see
> the need for it?  
> 
> I don't think I understand all the issues nearly well enough to comment
> further.  Maybe you can chew on it with Ian, who is pretty au fait with
> TH.

I'm not sure I got the need for the double encoding either. Talking it
over in person sounds like a good idea, Duncan.


Thanks
Ian