Re: language design tradeoffs

nickh@CS.CMU.EDU (Nick Haines) writes:
|> Jim Giles gives us some human-factors rules for statement termination
|> syntax:
|>
|> 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..
|>
|> This is much more difficult in languages with a broader expression syntax.
|> [...]
|> Many languages (e.g. SML) need statement terminators for this reason. A
|> sequence of identifiers:
|>
|> foo bar baz qux quux quuux
|>
|> could be any number of separate expressions in SML, depending on the
|> placement of the terminators.


Exactly. That's the purpose of the rule (1) I stated above: to explicitly
state what should be done with a language in order to avoid this problem.
In the above, you can't automatically detect the common error 'missing
statement terminator'. In fact, if you make that common error, you will
have a `correct' program which does something unintended - a fault which
may be hard to find in a large program.


If you find yourself tempted to design a syntax that makes statement
terminators *required*, I urge you to reconsider.


|> 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.
|>
|> And what about long statements? Surely not the dreaded `continuation marker'?


Yes, I do mean the dreaded continuation marker. See my earlier article on
this question. Continuation is rare and no one does it unless there is no
other choice. What's wrong with an explicit marker which emphasizes that
something unusual is afoot?


|> 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.
|>
|> I don't like this idea, but don't really know why.


Inadvertent commenting out of long sequences of code is a common error in
languages in which the scope of a comment is not constrained to a single
line. It also can leave valid code behind - again, an error that cannot
be detected automatically and may be hard to isolate (from experience with
real users, I can tell you that you can stare at such an improperly
terminated comment for ages and your mental picture of what's *supposed*
to be there will prevent you from seeing the problem). And, of course,
deliberately `commenting out' code is better handled with `ifdefs' or some
such concept.


If comments are terminated by the EOL, it's much harder to inadvertently
make such an error. This rule doesn't decrease your ability to comment
code, nor the legibility of such comments, it just restricts a common
cause of errors.


--
J. Giles
--

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