Can there be two?

> Way back in TT1 we compiled the templates down to an
optree which was
> evaluated at runtime.  However, I didn't make any real
attempt to
> optimise it (or didn't know how to at the time) and it
ran kinda
> sluggish.  When we switched to the compiled Perl for
TT2 we got a big
> boost in speed.  But looking at your numbers, it's
obviously that the
> optree approach can be just as fast if not faster if
done right.

The optree isn't faster at everything.  I can't beat large
while loops and
foreach loops that are running in native perl.

My optimized execution may also be getting some speed
benefit from my 
"provider" system.  It is possible that even on
the cached in-memory 
templates some of the perceived speed is coming because CET
is not doing 
something that TT is.  Combining the CET optree with the TT
provider may
end up in a net decrease of speed (nobody has tried it so
nobody knows).

> The TT3 parser is split into the classic front/back end
model.  The
> front end generates an optree (similar but slightly
different to yours),
> the back end then walks the tree to generate Perl code
(or Javascript,
> Ruby, C, etc).  The TT2 parse does a similar kind of
thing, but it's all
> internalised within the YAPP grammar and is difficult
to mess with.  TT3
> better defines the role of the optree, makes it more
accessible and
> generalises both the front and backs end so you can
plug in your own
> parser or code generator.
>
> So we could easily plug in a different back end which
effectively passes
> the optree back through (with a little bit of
finalising along the way)
> for runtime evaluation.
>
> In short, we should be able to make this kinda thing
work in TT3, no
> problem.

Neat.

> In a similar vein, the TT3 parser creates one big
structured expression
> for the parse tree.  The general form is:
>
>     [ type, args ]
>
> Or for a concrete example:
>
>     x + 3    => [add => [variable => 'x'],
[number => 3]]

Sort of funny - but I wrote a templating system that we use
at my current 
company (I wrote it 4 years ago - it grew to eventually have
many TT style 
features).  The language contructs are all in that sort of
notation (operator 
first).  It is very fast - faster than most of the engines
on CPAN, but it 
also has too much internal code and odd exceptions and poor
handling of 
nested data structure and warts and junk that I still prefer
using TT syntax.
TT syntax is much easier to understand.

That language looks like:

   This is printed.
   [if [&& form.a form.b] q{
      This is printed if form.a and form.b are true.
    } else q{
      This is not printed if they're true.
    }]
   [var a.n = [+ [* 2 3] [/ 5 6] [- 8 7]]]

> Anyway, if you can send me a link to the code I'd love
to take a good
> look through it and see what I can draw inspiration or
borrow code from.
>   There's some bits of the TT3 parser that I'm still
not happy with, but
> this could give me the last big push!

TT3 will be great.  I also can't wait for Perl6.  Because
then the parsing can 
become a grammar that outputs the tree.  That will be very
nice.  Ah - one 
can dream.  Sigh.

Paul

PS - I'll include the CGI::Ex::Template module in some
follow up code - I 
guess it would be better to let many eyes have a look at it
- even before its 
initial release.

_______________________________________________
templates mailing list
templatestemplate-toolkit.org
http://lists.template-toolkit.org/mailman/listinfo/t
emplates