Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!norvell
From: norvell@utcsri.UUCP (Theodore S. Norvell)
Newsgroups: net.lang
Subject: Re: Languages supporting x<y<z and those without semicolons
Message-ID: <3481@utcsri.UUCP>
Date: Sun, 12-Oct-86 15:14:58 EDT
Article-I.D.: utcsri.3481
Posted: Sun Oct 12 15:14:58 1986
Date-Received: Sun, 12-Oct-86 15:22:07 EDT
References: <1822@bu-cs.bu-cs.BU.EDU>
Organization: CSRI, University of Toronto
Lines: 46

The language Icon by Ralph Griswold supports (x<y<z) in an interesting
way.  Every expression in the language either succeeds or fails.  Success
and failure of expressions in Icon is much like success and failure
of procedure calls in Prolog, except that in Icon a succeeding expression
results in a value.  (By the way, just as a Prolog call can succeed more 
than once if backtracked into, an Icon expression can produce more than 
one result.)

Assuming x, y and z are arbitrary variables :
If x<y fails then x<y<z fails.
If x<y succeeds then its result is y and the whole expression becomes
y<z.  Now if that succeeds then the whole expression (x<y<z) succeeds
(resulting in z) else it fails.

By the way Icon also does away with most semicolons, though in a 
clumsy way.  If a line does not end in a semicolon, but it would
be syntactically valid for there to be one there then, the parser assumes
it's there.

A better way to get rid of semicolons in a free format
language is to design the grammar so that it needs neither statement 
(or declaration) separators nor terminators and is still LR(1).
An example is the Turing language.  Dave Brosius speculates that
this will make error recovery difficult.  However, error recovery in Turing 
compilers is quite good, and because there are no forgotten-semicolon 
errors less frequent than in Pascal ones.  It is almost as easy to recover 
by skipping to the next identifier which follows a ")", identifier or 
constant as it is to skip till the next semicolon.  My experience is 
that forgetting meaningful separators (like writting x := 1 x rather 
than x := 1 + x) is rare whereas forgetting syntactic artifacts like 
";", "(" and ")" is common.

Contrary to Barry Shien's Statement, it is not necessary to forbid 
assignments embedded in expressions in free form languages.
For instance this grammar will be unambiguous and LR(1).
	Expression --> Identifier  |  Identifier ":="  Expression  
		     |  "(" Expression ")"
	Statement  --> Expression
	Program    --> Statement | Program Statement.
If you still want semicolons in your language, add the production
	Statement   --> ";"
so that those who like to exercise there right little finger 
can put in all the statement terminators and/or separators they want.
				
				Theodore Norvell
				DCS U of Toronto