Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site harvard.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!macrakis
From: macrakis@harvard.UUCP (Stavros Macrakis)
Newsgroups: net.lang
Subject: New control structure
Message-ID: <768@harvard.UUCP>
Date: Mon, 10-Mar-86 13:35:18 EST
Article-I.D.: harvard.768
Posted: Mon Mar 10 13:35:18 1986
Date-Received: Wed, 12-Mar-86 21:33:57 EST
References: <1187@mmintl.UUCP>
Organization: Aiken Comp. Lab., Harvard
Lines: 36
Summary: ... can be easily implemented

Frank Adams (franka@mmintl.UUCP) writes that he often uses a control
structure which is hard to code using standard primitives.  I show
here that (1) his particular case can straightforwardly be programmed
and (2) that the general problem of which his is a special case cannot
be handled by any of the standard techniques.

His particular case can, in fact, easily be written (in Ada for example) as:

	Av := A; 			-- boolean A
	if Av then X; end if;		-- Av only needed in special case
	if (Av and then B) then Y;	-- where A and X interfere, or
	 else Z;			-- A is expensive
	end if;

His proposed solution is somewhat neater, but is it worth the (very)
special case?:

	if (A) then X;
          and if (B) then Y;
          else Z;

After all, in general, control structures of the form:
	[ <boolean function> => clause;
	  <boolean function> => clause;
	  ... ]
cannot be written -- not in flowcharts/goto programs, not in
if-then-else, not even in if-and-if -- in such a way that boolean
variables are not repeated.  `Decision tables' do clean up this
situation somewhat.

Adams also points out that some languages do not provide for
short-circuit boolean operators (or leave the semantics of boolean
operators up to the implementation!).  This is, as far as I can tell,
an entirely separate problem.

	-s