|[17 earlier articles]|
|Re: language design tradeoffs firstname.lastname@example.org (1992-09-17)|
|Re: language design tradeoffs email@example.com (1992-09-17)|
|Re: language design tradeoffs raveling@Unify.com (1992-09-17)|
|Re: language design tradeoffs firstname.lastname@example.org (1992-09-18)|
|Re: language design tradeoffs email@example.com (1992-09-19)|
|Re: language design tradeoffs firstname.lastname@example.org (1992-09-19)|
|Re: language design tradeoffs email@example.com (1992-09-20)|
|Re: language design tradeoffs firstname.lastname@example.org (1992-09-19)|
|Re: language design tradeoffs email@example.com.OZ.AU (1992-09-21)|
|Re: language design tradeoffs firstname.lastname@example.org (1992-09-21)|
|Re: language design tradeoffs nickh@CS.CMU.EDU (1992-09-21)|
|Re: language design tradeoffs email@example.com (1992-09-21)|
|Re: language design tradeoffs raveling@Unify.com (1992-09-21)|
|[11 later articles]|
|From:||firstname.lastname@example.org (Thomas M. Breuel)|
|Organization:||IDIAP (Institut Dalle Molle d'Intelligence Artificielle Perceptive)|
|Date:||Sun, 20 Sep 1992 00:44:25 GMT|
email@example.com (Jim Giles) writes:
|> >3) The EOL character should be the statement terminator. [...]
firstname.lastname@example.org (Rob Carriere) writes:
|> Hm. Did whoever did that research take large mathematical expressions
|> (which naturally translate to multi-line statements) into account? My
|> single most common syntax error in FORTRAN and Matlab is forgetting the
|> continuation marker on a multi-line statement.
Well, the experiment analysed error rates on a Pascal-like language. The
compiler at a university was rewritten to count the number of basic errors
and their causes. The result was that 20% of all syntax errors were
omitted semicolons at the end of a line. ...
Arguments like these for or against specific syntactic features are pretty
weak. First, consider the likely user population for a "Pascal-like
language" at a university. Second, the fact that (in this case) 20% of all
syntax errors happen to result from omitted semicolons tells you nothing
about the utility (or lack thereof) of those semicolons.
The thing you do less often should be the one which requires extra
notation - if only for emphasis.
While a language shouldn't go to extremes to make the syntax for commonly
performed operations cumbersome, the cost of typing a few extra characters
or fixing a few syntax errors because of what you call "extra notation" is
negligible compared to the cost of trying to track down bugs resulting
from the programmer having a different interpretation of the program text
than the machine. Language design should strive to choose syntax that
decreases the likelihood of such misunderstandings. Notational economy
doesn't necessarily make a language effective at achieving this goal, and
it may even hurt.
Return to the
Search the comp.compilers archives again.