Re: language design tradeoffs

jlg@cochiti.lanl.gov (Jim Giles)
Tue, 15 Sep 1992 18:39:55 GMT

          From comp.compilers

Related articles
[2 earlier articles]
Re: language design tradeoffs nr@dynastar.Princeton.EDU (1992-09-09)
Re: language design tradeoffs raveling@Unify.com (1992-09-11)
Re: language design tradeoffs weberwu@inf.fu-berlin.de (1992-09-13)
Re: language design tradeoffs rob@guinness.eng.ohio-state.edu (1992-09-14)
Re: language design tradeoffs tmb@arolla.idiap.ch (1992-09-14)
Re: language design tradeoffs macrakis@osf.org (1992-09-15)
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-15)
Re: language design tradeoffs anw@maths.nott.ac.uk (1992-09-16)
Re: language design tradeoffs drw@euclid.mit.edu (1992-09-16)
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)
[26 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: Tue, 15 Sep 1992 18:39:55 GMT
References: 92-09-048 92-09-066
Keywords: design, parse

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
--


Post a followup to this message

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