extensions

  Just for fun, I wrote a parser for the proposed filtering language.
It's pretty simple and clean; not hard at all.  The only problem came
up while writing the code to handle extensions used by the filter that
the interpreter doesn't know about.

  While handling commands and tests defined by unknown extensions is
fairly simple (commands go to the next ';', tests to the next ',' or
unmatched ')'), dealing with control structures defined by unknown
extensions is impossible.

  You can't just give up parsing the current block - even if you're in
an IF, there might be an IF after the extension (so you can't just go
to the next ELSIF/ELSE/ENDIF), or the extension might use one of those
atoms (so you *really* can't just go to the next ELSIF/ELSE/ENDIF).
(You also can't recover to the next ';', as a control structure may
embed commands, and control structures don't end with ';'s).

  In short, you lose - an extension you don't know about is by
definition a parse error, and there's nothing to synchronize against
to let you keep parsing.

  We need to either
   a) Make the grammar more regular with respect to control structures
      (maybe a standard block syntax, like C's {}s or Lisp's ()s?),
   b) Require that control structures end with some standard
      terminator, or
   c) Forbid extension control structures.

  )Rob