in it.

discussed in today's meeting.

- Don't use a wrapper function around macroIndexer.

Running the test suite with this version ("./runtest.sh -c") now shows
two failures:

- test2: the checked-in test output is missing the xmlns="..."
  attributes because the Printer module doesn't emit these for
  prefix-less xmlns attributes (in cases where node.namespaceURI is
  set but node.prefix is None).

- test8: this version emits a redundant xmlns:m attribute on the
  expanded macro element.  AFAICT this is OK according to the XMLNS
  standard.  The redundant attribute is emitted because macros are
  compiled without context (since they may be used in a different
  context).

- Added (untested) insertStructure().

(by applying str() if it is neither).

- z:omit is gone

- new, separate command to loop over a subtree: <tag z:repeat="var expr">

- remove syntactic sugar from z:define (no "as"), z:attributes (no "=")

TALInterpreter needed no change.

Note that TALCompiler doesn't yet emit proper xmlns attributes.

- z:omit is gone

- new, separate command to loop over a subtree: <tag z:repeat="var expr">

- remove syntactic sugar from z:define (no "as"), z:attributes (no "=")

- refactored a bit to accommodate this

next version of the syntax.

status 0.

TALVisitor.

  getAttributeNodeNS().

- Move parseAttributeReplacements() and splitParts() out of the class
  (they can be simple functions), so they can be imported by
  TALCompiler and TALInterpreter.

- Remove a redundant key argument from doReplaceLoop() and
  doInsertLoop().

- Add an XXX comment warning that we don't check for z:replace on the
  documentElement.

This really makes a difference!  Some timing statistics (on
test/test2.html, a document with no TAL contents):

talizetree    :  2.190 secs for 10 calls, i.e.  219 msecs per call
printtree     :  2.870 secs for 10 calls, i.e.  287 msecs per call
compiletree   :  0.250 secs for 10 calls, i.e.   25 msecs per call
interpretit   :  0.110 secs for 10 calls, i.e.   11 msecs per call

There are two ways to go from a DOM tree to text (the assumption is
that the DOM tree is already in memory):

talize + print    : total 506 msec
compile+interpret : total  36 msec, or about 14x faster

If we cache the compiled program, we're down to 12 msec, or over 40x
faster.

So compilation + interpretation are well worth it!  (I.o.w., creating
a DOM tree is very slow.)

- Recognize command line options.