Chris Newman <Chris(_dot_)Newman(_at_)innosoft(_dot_)com> writes:
On Wed, 21 Jan 1998, Rob Earhart wrote:
Nope - you *can* do your semantic checking in your parser, even
under this scheme. I'd argue that this makes your parser needlessly
complex and hard to maintain, when the work's better split up and done
at a higher level, but that's just my opinion.
Functional separation is good. Layers are bad. I've never been a fan of
multi-level grammars -- in my experience they make things less reliable
and harder to understand. Every time you introduce a layer you partition
part of the problem into very complex cross-layer communication issues
(your if-then-else example is one case). Even a layer as necessary and
delinated as TCP has these problems (think IP security, urgent data,
SIGPIPE).
[snip]
So I see this as a proposal to constrain the human readability of the
script for all time in order to save a few programmer hours. This seems
like a really bad tradeoff to me.
Your argument seems inconsistent to me. First you suggest that a
"multi-level" grammar is complex and hard to understand, then you
argue that it will "save a few programmer hours", (one can only assume
that's because it's actually *less complex*). But you're opposed to that
because it "constrains human readability". Then, in another note,
you argue that less than 5% of users will write their own scripts, which
leaves me wondering why human readability matters so much....
If we want to compromise on this issue, I suggest we define the rules for
skipping a command (look for unquoted ";"), and let extensions which add
new control structures do whatever they wish. New control structures will
be rare. I also don't object to suggestions for what the syntax of
extensions should look like -- just don't make them recommendations or
requirements.
I think this is on the right track, though I would prefer to see a more
formal
rule than "look for unquoted semi". Tim's recently posted grammar seems
like a good starting point. (Maybe somebody could post an example of
a "reasonable" extension which can't be accomodated by this grammar?)
This will at least allow implementations to use a conventional
AST (abstract syntax tree) implementation, and to easily support dynamically
loaded extensions without requiring (horror!) parsing callbacks and the
like.
Stan