(Tim asked me to go over the grammar...)
The example in section 3 is bad, as has been pointed out on the list:
else is followed by a block, you can't put a command (like "if") there.
If you could, you'd be allowing the thing after an if or an else to be a
command, allowing you to write "if (foo) if (bar) baz; else qux;", which
is ambiguous to an LALR(1) parser. So, yeah people need to use elsif,
they can't just use "else if".
I thought we'd agreed that the rule was, "Tests don't have
side-effects", which meant that whether or not short-circuit evaluation
was performed was implementation-defined (you'd have no way to tell)?
require: I wouldn't mind making it Magical; all require commands have to
come at the top of the script, and they're illegal after the first
non-require is processed.
Note that the way WSP is defined, something like
foo; # do foo
# because it's good
is illegal -- the space after the ';' is the after-command [WSP] in
commands, so the comment has to be the before-command [WSP] in
commands, so the spaces on the next line (not to mention the
comment) are illegal; there *must* be an indentifier there, to start
a command.
Heck,
foo;# This is the after-command [WSP] in commands
# This is the before-command [WSP] in commands
# This is illegal
This could probably fixed by putting the alternative inside the 1* in
the WSP rule.
As written, the grammar has a shift/reduce conflict related to the way
tests are handled. Here's an example of the ambiguity:
anyof allof true
The thing is, a test is an identifier, followed by zero or more arguments,
followed by an optional test-list. A test can be an argument, though. So
in this case, "allof" is an argument to "anyof", but "true" could be an
argument to either -- the scanner doesn't know whether to shift, making it
an argument of "allof", or reduce "allof" to a test and make "true" an
argument of "anyof".
I'd solve this by removing "test" as a possible "argument", and putting
an optional "test" into the rule for "command", just before the block /
";". I think this still fits with all the existing commands, and makes
the system as a whole cleaner. I thought about making seperate "command
arguments" and "test arguments", where test arguments couldn't themselves
contain a test, but that leaves open another subtle hole:
command test "foo";
can be parsed with "foo" being an argument to the test (if shifted) or to
the command (if "foo" is reduced). The other thing which came to mind was
to require that tests used as arguments be parenthesized, but that would
be a pretty significant change -- nothing that uses tests bothers
parenthesizing them, in the current spec.
The grammar might be simpler if it were chopped it into seperate
lexical, syntactic, and semantic sections -- then it'd be a lot easier to
avoid mistakes like not allowing comments inside an empty block, and it
wouldn't have all the [WSP] all over the place. It'd be easier to read
and easier to use, too.
(I'll volunteer to write the grammar... it'd be a nice way to relax.)
)Rob