Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!think!snorkelwacker!mit-eddie!uw-beaver!uw-june!fred.cs.washington.edu!machaffi
From: machaffi@fred.cs.washington.edu (Scott MacHaffie)
Newsgroups: comp.lang.misc
Subject: Re: Anyone want to design a language?
Message-ID: <10790@june.cs.washington.edu>
Date: 19 Feb 90 21:38:58 GMT
References: <22569:05:10:24@stealth.acf.nyu.edu> <8475@wpi.wpi.edu> <4489:05:14:19@stealth.acf.nyu.edu>
Sender: news@cs.washington.edu
Reply-To: machaffi@fred.cs.washington.edu.cs.washington.edu (Scott MacHaffie)
Distribution: usa
Organization: of
Lines: 20

In article <4489:05:14:19@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:
>14. Control flow statements, control structures: [ various ]
>
>I have some rather heretical thoughts on this subject. I'll make them
>clear in another message. (Remember that this isn't Ada. Given an
>infinite loop ... endloop, if, and break, you don't need to provide
>a terminating loop as a basic construct. Define it instead as a standard
>macro. Ada's infinite variety of control structures is awful.)

Unconditional loops have a serious problem: you have to read all of the
code inside the loop to find out when (or if) it terminates. Replacing
while and for with loop would be a bad idea. Even providing loop
means that people will use it and stick "end loop" inside the loop
(this happens in ada).

The advantage of a while/for loop is that the terminating condition
(or at least the standard terminating condition) is easy to find.
Then, only exceptional terminating conditions are inside the loop.

			Scott MacHaffie