Path: utzoo!mnetor!uunet!ncc!alberta!att-ih!ihnp4!ihlpf!warren
From: warren@ihlpf.ATT.COM (Montgomery)
Newsgroups: comp.software-eng
Subject: Control flow and common sense
Message-ID: <4605@ihlpf.ATT.COM>
Date: 2 May 88 14:28:24 GMT
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 34
Keywords: gotoless programming, finite state machines

Control flow seems to be an area that brings out the worst in
people.  There isn't one set of control structures that is right for
every problem.  If you want to look for the ultimate in gotos, look
at some of the constructs that the AI folks use:  Production rules,
pattern directed invocation, blackboards, etc.  That doesn't mean
that these are bad, just that the problems they are solving lend
themselves to different kinds of control flow.

One of the most difficult to understand programs I ever came accross
was a "gotoless" program written shortly after the original Djikstra
article.  It was a printer driver that consisted of a large outer
loop "while (not_done)" and a loop body that consisted of deeply
nested if-then-else's.  At the leaves of the if-then-elses were
statements that did something and generally set variables tested by
the if-then-elses, possibly also setting the loop condition.  The
structure being implemented was actually a finite state machine, and
fairly simple to understand as such, but impossible to discern from
the style in which it was written.

What I'd like to suggest is this:

	1) Use control structures that are appropriate for your
	application and readily understood.  For many problems,
	loops and conditionals are natural control structures, but
	some applications naturally call for finite state machines,
	production rules, or more exotic strucutres.
	
	2) Use an implementation that makes that control structure
	explicit.  Implementing a finite state machine obscurely to
	avoid gotos doesn't make the program more maintainable.
	
-- 

Warren Montgomery ihlpf!warren