Randal L. Schwartz wrote:
> Damn you, Andy. :)
Sorry :-)
> Speaking of that, how's TT3? You should use the MJD parser for that.
I came pretty close to getting the core modules finished by January of
this year. Then our second baby came along. Then the money ran out and
I had to go and get a real job again. :-(
So right now I'm busy doing various bits of TT-related consultancy work
to keep the food on the table (in the short term) and to build up some
funds to allow me to take some more time off to finish it off (in the
long term), or at least move a few steps closer.
So although I'm not churning code right now, I am still spending a lot
of time working on design aspects and trying to iron out some of the nasty
corners in my head. The parser, in particular, has made my brain hurt
and often. If it were as simple as using an existing parser, then I would
very much like to.
The problem is that TT has some very demanding requirements of a parser,
and TT3 especially so. A purely state-table-driven parser (as in TT2)
isn't flexible enough for a language as flexible as TT. There are numerous
rough edges in the TT2 language caused by the inability of the parser to
Do The Right Thing when pushed.
A recursive descent parser, on the other hand, has the flexibility to
handle the special-cases of the TT language. Unfortunately, the nature
of a RD parser (parse_template() calls parse_tag() calls parse_directive()
calls parse_expression() and so on) is such that it becomes very difficult
to separate the front-end and back-end of the parser.
This is important because the TT language isn't regular. Tags and directive
are not always nested. Unlike XML and other structured markup, they can
overlap in TT, with tags containing several directives, or directives
being spread across several tags:
[% IF x; INCLUDE y; END %] # one tag, multi-directive
[% IF x %] # one directive, multi-tag
blah
[% END %]
So the TT3 parser has a front end scanner (which handles the tags) sending
parse events to a back-end handler (very much like XML::SAX). Then we have
a table-driven parser to handle the grammatical structure of the block
directives (working out which block is nested in which block and which
keywords signify the start/end of the directives). Finally we have a
recursive descent parser at the bottom to parse the individual elements
of the TT language (expressions, variables, etc.)
It's a real bastard hybrid, quite probably unlike anything currently known
to man. But it should be fast, forgiving and extremely flexible.
Cheers
A
_______________________________________________
templates mailing list
[email protected]
http://lists.template-toolkit.org/mailman/listinfo/templates
