Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!caip!princeton!allegra!ulysses!mhuxr!mhuxt!houxm!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: net.lang
Subject: Re: compound statements
Message-ID: <800015@ccvaxa>
Date: Sun, 13-Jul-86 11:32:00 EDT
Article-I.D.: ccvaxa.800015
Posted: Sun Jul 13 11:32:00 1986
Date-Received: Mon, 14-Jul-86 22:28:07 EDT
References: <5281@topaz.RUTGERS.EDU>
Lines: 57
Nf-ID: #R:topaz.RUTGERS.EDU:5281:ccvaxa:800015:000:2094
Nf-From: ccvaxa.UUCP!aglew    Jul 13 10:32:00 1986


... > Discussion of compound statements for procedure bodies;
... > ambiguity in null statements without BEGIN..END brackets.

Personally, I prefer PROCEDURE..END PROCEDURE brackets (single character
symbols if the character set is large enough - hell! I prefer LISP 
parentheses) but would like to point out that the above problem with
null statements only occurs because the null statement is BEGIN..END
or {} or ;, ie. because the null statement is implicit.

Dijkstra argues that making the null statement explicit, `skip', with
defined semantics, may be as important for computer science as the
invention of zero was for arithmetic. 

On many occasions I have found that explicitly putting in a null statement
(in whatever form the language permits) is clearer than not; ie.

    if( long_and_complicated_condition )
	/* do nothing */;
    else {
	...
    }

is easier to read and maintain (and add debug lines to) than

    if( !( long_and_complicated_condition ) ) {
	...
    }
    
with no else branch. Especially if somebody has tried to `simplify' things by
applying DeMorgan's rule.


I would take this further, and say that for every class of construct there
should be a null construct. C, for example, has a null statement in a
solitary semicolon, but doesn't have a null declaration, ie. a declaration
that declares absolutely nothing.

	foo()
	{
	    int a;
	    ;
	    int b;

isn't allowed. That's not really serious; something that I have thought would
be more useful would be a null character - not '\0', but a character that
generates no output in strings, just acts as a place holder. It would be nice
to break up long escape command sequences in strings, so that you can see the
components: "\e[1;8...\em9..." where ... is the place holder. Although
ANSI C with string constant concatenation does better "\e[1;8" "\em9" ...


OK, who's going to tell me I'm brain damaged now? I hope that they can do
arithmetic in Roman numerals...

Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801    ARPAnet: aglew@gswd-vms