Re: language design tradeoffs

jlg@cochiti.lanl.gov (Jim Giles)
Thu, 17 Sep 1992 18:52:54 GMT

          From comp.compilers

Related articles
[11 earlier articles]
Re: language design tradeoffs rob@guinness.eng.ohio-state.edu (1992-09-17)
Re: language design tradeoffs bromage@mullauna.cs.mu.OZ.AU (1992-09-17)
Re: language design tradeoffs jch@rdg.dec.com (1992-09-17)
Re: language design tradeoffs firth@sei.cmu.edu (1992-09-17)
Re: language design tradeoffs nickh@CS.CMU.EDU (1992-09-17)
Re: language design tradeoffs norvell@csri.toronto.edu (1992-09-17)
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-17)
Re: language design tradeoffs bks@s27w007.pswfs.gov (1992-09-17)
Re: language design tradeoffs raveling@Unify.com (1992-09-17)
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-18)
Re: language design tradeoffs e86jh@efd.lth.se (1992-09-19)
Re: language design tradeoffs maniattb@cs.rpi.edu (1992-09-19)
Re: language design tradeoffs tmb@arolla.idiap.ch (1992-09-20)
[17 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers,comp.human-factors
From: jlg@cochiti.lanl.gov (Jim Giles)
Organization: Los Alamos National Laboratory
Date: Thu, 17 Sep 1992 18:52:54 GMT
References: 92-09-048 92-09-093
Keywords: design, parse

rob@guinness.eng.ohio-state.edu (Rob Carriere) writes:
|> jlg@cochiti.lanl.gov (Jim Giles) writes:
|> >Statement termination syntax design rules (as derived from human factors
|> >experience):
|> >3) The EOL character should be the statement terminator. [...]
|>
|> 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. (See: Ripley and Druseikis: "A
Statistical Analysis of Syntax Errors", Computer Languages, vol.3, 1978,
227-240.) Ellis Horowitz, summarizing this and other results in his book
(Fundamentals of Programming Languages, 2nd edition) says "this seems to
be a result of the fact that people regard the end of a line as the end of
a statement."


With regard to continuation: yes, long mathematical expressions can result
in statements that exceed one line. This is not as common as you might
think. I did an informal survey of source code available to me and found
that only 2% of all Fortran statements needed continuation (and most of
those - in my case - turned out to be LOGICAL expressions in IF
statements). The source for commercial C products I looked at had a total
of 12 statements (not counting "compound statements", which are actually
statement *blocks*) that actually crossed line boundaries out of over
10,000 statements of code (this is in spite of the fact that C directly
allows this). This makes the feature of allowing statements to cross line
boundaries one of the least heavily used features of C (except in
obfuscation contests, of course). Certainly, my own observation is that
people tend not to put line breaks within statements unless there's no
choice - in which case, an explicit mark denoting that something unusual
is afoot seems not amiss.


My conclusion is that omission of an statement terminator (if EOL doesn't
serve as one) is probably more common, in general, than even *needing*
continuation. The thing you do less often should be the one which
requires extra notation - if only for emphasis. In any case, the language
should certainly be designed so that an omitted continuation and/or an
omitted statement terminator can automatically be detected even if you
decide not to *require* such marks in your language. The programming
language Turing requires neither type of marks. The price is less
localizability of certain types of syntax error.


--
J. Giles
--


Post a followup to this message

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