I have included a test program that tests what I am requesting. I would like to see the status of reserved words become a little less reserved. There is a lot of intuition that can be gathered based upon the place you are in.
Basically it seems the only place that a reserved word should be reserved is
anywhere that a directive could be placed - that is at the beginning of a
tag, or anywhere where a post directive can be used.
Below are some sample vars and what the optimum (in my opinion) output should
be. Intermixed with the output I have included the current status of what
TT2 does (anything that says fails means that the TT2 engine currently
fails).
Again - this is all subject to the grammar engine being able to tell if it
should be looking for a directive at any given point or not (sort of how if
perl6 is looking for a term or expression or block at various states of the
parse).
my $vars = {
GET => 'named_get',
get => 'lower_named_get',
named_get => 'value of named_get',
hold_get => 'GET',
};
1..15
ok 1 - use Template;
# good that this works :)
ok 2 - "[% GET %]" => ""
# correct - GET is in a space where a directive is possible (usually
# expected)
ok 3 - "[% GET GET %]" => "named_get"
# fails - There isn't any ambiguity here. We want to get a variable named
# GET
ok 4 - "[% GET get %]" => "lower_named_get"
# correct - so long as ANYCASE isn't set
ok 5 - "[% GET = 1 %][% GET GET %]" => ""
# correct - the variable name is in a spot where a directive is expected
# can't fix this
ok 6 - "[% SET GET = 1 %][% GET GET %]" => "1"
# fails - There isn't any ambiguity here
ok 7 - "[% foo = {GET => 1} %][% foo.$hold_get %]" => "1"
# fails - Even though the key should be autoquoted - it still fails
ok 8 - "[% 'GET' %]" => "GET"
# correct - this works most likely because '' and "" are a single parsed
# token
ok 9 - "[% GETS %]1" => "1"
# correct - looks like undefined variable access
ok 10 - "[% GET $hold_get %]" => "named_get"
# correct - we can access the hash via named access
# you could also do [% name='G' _ 'ET' ; GET $name %]
# but that is a hack
ok 11 - "[% GET $GET %]" => "value of named_get"
# fails - even though it looks like a named access
ok 12 - "[% BLOCK GET %]hi[% END %][% PROCESS GET %]" => "hi"
# fails - though the blockname and autoquoted process name shouldn't
# confused by reserved words
ok 13 - "[% BLOCK foo %]hi[% END %][% PROCESS foo a = GET %]" => "hi"
# fails - process is looking for a named argument value - should be
# unambiguous
ok 14 - "[% BLOCK foo %]hi[% END %][% PROCESS foo GET = 1 %]" => ""
# correct - There could be a post operative directive at that point - so
# you can't use a directive there. Arguably you could keep the definitive
# list of which items are post operative and then only that set would be
# reserved at that location.
ok 15 - "[% BLOCK foo %]hi[% END %][% PROCESS foo IF GET %]" => "hi"
# fails - This should be fine - as IF is expecting a value at that
# position
Again - I don't know if this request is even possible with the grammar engine.
It does seem like it gives the template writers the most flexibility without
imposing unnecessary restrictions on them. Then there is the argument that
letting users do this could produce some very ambiguous edge cases (which
they will do) - but I don't know if that is a good enough reason to prevent
other users from using reserved words in unambiguous positions.
Love to here any feed back - and no I don't have code patches to bring the
Grammar.pm into alignment - but before work is done on it I'd like to see
what people's opinions are.
Paul Seamons
reserved_words.pl
Description: Perl program
