Re: language design tradeoffs

Statement termination syntax design rules (as derived from human factors
experience):


1) Statements should be distinguishable from one another even *without*
any terminator or separator. Ie. `x = a+b c = 157.5' is obviously two
statements because otherwise you have to devise a meaning for two
consecutive identifiers, allow assignment within expressions, etc..


2) Statements should be explicitly terminated (not separated). Even
though statements can be told apart without such termination, the added
redundancy is not obtrusive and allows errors (which might otherwise be
difficult) to be localized better. That is: `x = a + ;c = 157.5;' is
clearly missing an operand in the first statement, not affecting the second
at all.


3) The EOL character should be the statement terminator. For flexibility,
another statement terminator should be recognized which allows more than
one statement per line. The semicolon (;) is a good choice for this.


4) Comments should also be terminated by the EOL character, so that a
statement is terminated either by a semicolon, a comment, or a bare EOL.
And a comment is only to the end of the present line. Comments may
contain semicolons without them terminating the comment.


5) The concept of `statement' should not be confused with whatever
syntactic structure is used for blocking groups of statements in flow
control and scoping constructs. That is, there should be no concept of
`compound statements' at all. Scoping and flow control should be done
with specific block control statements which separately denote both the
beginning and the end of each such block. These block control marks
should follow all the preceeding rules as if they were statements.


Now, I suppose there is still some room for taste and opinion. For
example: whether `if ... fi' or `if ... endif' should be the statements
denoting the bounds of the IF construct. Reverse spelling is not really
very natural, but can be learned. These issues are secondary to the main
issues addressed above.


--
J. Giles
--

Return to the comp.compilers page.
Search the comp.compilers archives again.