Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!hplabs!sri-unix!garth!phipps
From: phipps@garth.UUCP (Clay Phipps)
Newsgroups: comp.lang.misc
Subject: Re: Algol-style semicolons
Summary: ...or use introductory tokens ("introducers" ?) to start statements.
Keywords: semicolons,terminators,introducers,triggers
Message-ID: <2276@garth.UUCP>
Date: 22 Dec 88 00:54:37 GMT
References: <1126@etive.ed.ac.uk> <208100002@s.cs.uiuc.edu> <868@mcrware.UUCP> <8008@aw.sei.cmu.edu> <GARY.88Dec15142623@milo.mcs.clarkson.edu> <88Dec16.100919est.4327@turing.toronto.edu> <9235@ihlpb.ATT.COM>
Reply-To: phipps@garth.UUCP (Clay Phipps)
Organization: INTERGRAPH (APD) -- Palo Alto, CA
Lines: 76

In article <9235@ihlpb.ATT.COM> nevin1@ihlpb.UUCP (55528-Liber,N.J.) writes:
>In article <88Dec16.100919est.4327@turing.toronto.edu>, 
>perelgut@turing.toronto.edu (Stephen Perelgut) writes:
>|Another method of handling semi-colons is to not have them.  
>|All you need to do is terminate multi-part statements.  [example shown] 
>|There are no ambiguities there!  And the only cost is terminating a statement.

>You still need a way of saying that an expression is to be continued on
>the next line (or that you don't need to continue a statement by
>use of a separator or terminator; this amounts to the same thing).

I have long been fond of using the opposite of terminators; one might call 
them triggers, introductory tokens or "introducers" ("initiator", intended
as opposite of "terminator", might be confused with value initialization).

Most Algol-derived languages that I know of have an introducer -- a keyword
-- for every statement type except assignment and (usually) procedure calls
and (sometimes) value returns.  Treated as statements, "end if", "end loop",
&c. fit well into such a scheme: they are brackets at the semantic level.

The language CMS-2 uses few special characters; the almighty dollar "$" 
is its terminator symbol (one particularly appropriate for the military :-).
Unlike most languages on the Algol side of COBOL, CMS-2 uses 
an introductory token for every statement (except procedure calling ?)
When I first saw the assignment statement form:
 
	"SET" TargetObject "TO" SourceValue "$"

I immediately thought of COBOL verbosity, but was surprised to realize that 
in practice, I could type "SET" and "TO" faster than I could find and type
the (shifted) ":" and (unshifted) "=" to form an Algol assignment token 
(we used 3 different keyboards on that project, none with ASCII layout).
In the CMS-2Y "structured programming" dialect of CMS-2,
the "$" was more of an artifact than a necessity, even for error recovery.

I believe that a syntax style that uses introducers rather than
terminators for all (or all but one) statement type combines 
the source-layout and error-recovery advantages 
of always-terminated statements, and 
and the easy modifiability (lack of "%#@!  I forgot to insert|remove...!") 
and typing speed advantages of never-terminated statements,
to the greatest extent possible for those conflicting goals.

Fleshing out the example by perelgut@turing.toronto.edu (Stephen Perelgut)
along these lines, I have
 
 	if x then
	    get p from p^.next  -- compute the value p^.next; store in p
	    give p^             -- return the value p^
	elsif y then
	    get p from p^.prev  -- compute the value p^.prev; store in p
	    give p^             -- return the value p^
	else
	    give nil            -- return the nil value
	end if

Notes: The "--" introduces a comment, which continues to CR | LF.
I replaced "set" by "get" to avoid confusion with Pascal powersets, and 
chose the shortest sensible English words for keywords, to minimize typing.

The scheme allows not only statements continued over multiple lines, 
but also multiple statements on a single line (e.g., when nonpurists 
would agree that keeping everything on a page promotes comprehension
to a greater extent than isolating each statement on 1 line).
The only thing that does not work smoothly is imbedded assignment,
although that could be done via parentheses.
The style shown here best fits statement-oriented, rather than
expression-oriented, languages.

I recognize that all this is not earth-shaking programming language theory;
it is just my 2 bits worth on reducing common sources of aggravation.
It may already have been done, perhaps by the ABC folks at CWI/Amsterdam.
-- 
[The foregoing may or may not represent the position, if any, of my employer]
 
Clay Phipps                       {ingr,pyramid,sri-unix!hplabs}!garth!phipps
Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403            415/494-8800