Hi,
I've been playing around with directives for the
last day, thinking about how pluggable directives
would work best and what some of the current
problems are.
Brian Goetz and I have been shooting a couple
emails back and forth regarding the subject
and he has found that using a JAVACODE
production solves the problem for WM. A JAVACODE
production is basically a mini hand written
parser in the midst of a generated JavaCC
parser. The need for a JAVACODE production
arises from contextual ambiguity. For example:
#foreach $element in $list $element #end
1 2 3 4
If all directives are pluggable then there
is nothing specific in the grammar to
catch a #foreach $element in $list. You are basically
looking for #anything, then a list of arguments.
In the above example it's not possible to tell
that (4) is in the body of the #foreach without
giving the parser a hint i.e. the number of
arguments to the directive. So a #foreach has
three arguments so what follows must be the
body of loop.
Now what Brian has come up with is really
quite ingenious! But I believe there is a
simpler solution. The JAVACODE production is
required by the mere presence of contextual
ambiguity. So I say remove the contextual
ambiguity and use a much simpler mechanism,
removing the need for a JAVACODE production.
I've had discussions with Terence about this,
having well defined entry/exit
points for certain parsing operations. For example
JavaDoc has the very simple /** */ entry/exit
markers. And in the chat room last night Geir
suggested the same type of system for pluggable
directives.
So to remove the contextual ambiguity, and the
requirement of a JAVACODE production I would say
that delimiting the arguments for a directive
would be much simpler and actually be more
flexible:
#foreach ($element in $list) $element #end
What this would also allow is a variable
number of arguments to the directives. Here's
hypothetical examples of where a variable number
of directives might be useful.
#set $greeting = "Hi $name! Well you know $today is your lucky day!"
#expand ($greeting with $a $b)
But you could put as many parameters in $greeting as you
liked, and you could expand the greeting with the list
of values to match those parameters. Maybe a contrived
example and useless but I'm sure a variable number
of arguments to a directive might be useful.
The #set directive would be an exception, it would
look as it does now. But even single argument directives
would have to be enclosed in the delimiters. So we
would have things like the following:
#foreach ($element in $list)
$element
#end
#expand ($greeting with $a $b)
#escape ( $a ) [ not in VM just using a WM example]
But directives with no arguments could probably
just be left as:
#compress
text to
compress
#end
I wanted to throw the idea out and see what people
thought. I think it would make things a great
deal simpler WRT pluggable directives and a lot
more flexible. You could decide to have optional
parameters to a directive, and you could look
for the number of directive arguments passed to
the directive then decide how to proceed.
If people are in agreement then I would like to
make the changes ASAP and alter the testbed
and give it a whirl!
Comments?
jvz.
--
Jason van Zyl
[EMAIL PROTECTED]
