Date: Wed, 21 Jan 1998 10:13:56 -0500 (EST)
From: Rob Earhart <earhart+(_at_)cmu(_dot_)edu>
X-Face:
,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_(_at_)0"_qA\(_at_)g8N:'pK!bM
tSE)?S,#(_at_)MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~>
Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu> writes:
This cuts over 30 lines off the formal grammar. Anyone claiming this
reduces complexity is wrong; it merely moves it out of the parser and up a
level to where the script can't be essentially validated by the parser.
It reduces complexity; it seperates command/argument checking from
syntactic analysis (making both simpler) while maintaining
extensibility. (You've still got the same amount of *work*, it's just
simpler. :-)
No, this is wrong. Where before I had a parser that could check the types
of my arguments, I now have to write another layer.
This does mean that (assuming the way I write interpreters :-), in
semantic analysis, a control-structure implementation module needs to
be passed a pointer to the previous control-structure (if the prior
element was a control-structure) so that, for example, "else" can
check that it's preceeded by an "if". That's not a big deal at all,
though, and I love the flexiblity of being able to dynamically add
more control-structures...
It's not that simple.
if (...) { ... }
fileinto ...
else { ... }
Real languages just make the else part of the control structure. I want
that.
Ned Freed <Ned(_dot_)Freed(_at_)innosoft(_dot_)com> writes:
How do you do an if-then-else in this grammar?
if (test) { commands } else { commands }
(As Tim noted, trying to explain it in terms of the syntax elements
is a lose - but this should be familiar enough to people.)
Actually, what I meant is that it took me more than five seconds to explain
to *myself* how I expected this to work. This is bad.
I object to the way control-structures are specified. There are two
solutions: first, come up with the four control structures deemed
absolutely necessary (if, while, cond, for), and require full-blown
grammar-changing extensions for anything anyone else might want to do;
second, figure out a delimiter so that a control structure can essentially
take multiple blocks.
The only grammar suggestion I have is that tests in
control-structure look a lot like string-list elements, at least when
you first hit them - is there any chance we could use a different
pair of characters to bracket string-list? Say, '[' and ']'?
I considered that; I'm sort of apathetic towards it.
(It'd be nice if actions could take the results of tests in their
arguments; then the distinction between control-structure and action
could vanish... but as is, it's only a few extra states in one's
parser DFA to keep track of whether the current command's been
restricted to being a control-structure or not; it's not a big deal.)
There's an important difference between control-structures and actions.
Since you no longer know how many arguments any given thing takes, the
end-of-statement token is either a block or a semicolon.
To be completely pedantic, however, there's no way to take results of tests
in your arguments because we never state if things are call-by-name or
call-by-value.
--
Tim Showalter
tjs+(_at_)andrew(_dot_)cmu(_dot_)edu