[Template-haskell] RE: Partial evaluation using TH
igloo at earth.li
Fri Jan 2 17:11:08 EST 2004
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
> compileProg = $(cogen [| [| evalProg |] |])
OK, but if I have something like
do e <- [| evalProg' |]
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
I'm not sure I got the need for the double encoding either. Talking it
over in person sounds like a good idea, Duncan.
More information about the template-haskell