Paul Seamons wrote:
I have a further proposal that I didn't really think should be in a separate
proposal email as it is a rather fundamental change to TT. I would highly
suggest using the intermediate AST (abstract syntax tree).
Oh yes, absolutely. That's been a feature of the TT3 parser since the very
beginning. Apart from anything else, it's been very useful for debugging and
testing. I bolted on a debug dumper and created a bunch of test/expect tests
like this:
-- test binary additional --
foo + bar
-- expect --
<binary:
<variable:
<node:
<ident:foo>
>
>
<op:+>
<variable:
<node:
<ident:bar>
>
>
>
-- test args and ranges no commas --
a(10..20 30 40..50)
-- expect --
<variable:
<node:
<ident:a>
<args:
<range:
<number:10>
<number:20>
>
<number:30>
<range:
<number:40>
<number:50>
>
>
>
>
In TT1, the whole process was AST/opcode driven but probably not done very
efficiently. For TT2 we skipped the whole AST and went straight to Perl. For
TT3 the parser builds the AST and one of the Template::Generator modules
(currently T::D::Perl and T::D::Debug) handle the transformation.
There is no reason that the raw data could also be turned into Parrot
AST, or Perl 6.
Or C. It's a bit of a pipe dream, but it would be rather nice to be able to
compile a bunch of templates down to a C library and dynamically link them
straight into the Apache process.
Another reason for using the AST model is that I have found that compiled Perl
5 code only beats AST if you are running in a mod_perl environment. In a
situation where you have to read from file cache, or if you have to compile
fresh (such as from a string ref) every time - then running off the AST is
faster as you can skip the intermediate code generation/evaulation step.
Yep, that makes a lot of sense. In the pass you make over the AST to generate
Perl code, you might as well evaluate the template on-the-fly. So I guess
that should be something we can set as an option. Or even some combination of
the two - you evaluate the AST on-the-fly when it's first requested, then walk
the AST again to generate Perl if and when the template gets cached for reuse.
A final reason for using the AST is that you can then avoid having to store
perl written by the Apache server.
Do you meaning storing to disk? What's the alternative, a custom bytecode
format or a straight serialised AST?
Alloy also offers two stage compilation - on the
first hit you get AST, but on the second hit to the same document in a cached
object you get compiled perl. I'd love to see this in TT3.
Ah right. That sounds like you've already implemented what I was getting at a
paragraph or two ago. You're one step ahead of me again. Sounds good. :-)
Cheers
A
_______________________________________________
templates mailing list
[email protected]
http://lists.template-toolkit.org/mailman/listinfo/templates
