Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!bu.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.misc
Subject: Re: Anyone want to design a language?
Summary: Transfer of control needs to be varied and flexible
Message-ID: <1966@l.cc.purdue.edu>
Date: 26 Feb 90 15:46:22 GMT
References: <22569:05:10:24@stealth.acf.nyu.edu> <8475@wpi.wpi.edu> <24123:04:14:07@stealth.acf.nyu.edu>
Organization: Purdue University Statistics Department
Lines: 25

In article <24123:04:14:07@stealth.acf.nyu.edu>, brnstnd@stealth.acf.nyu.edu writes:
> In article <10790@june.cs.washington.edu> machaffi@fred.cs.washington.edu.cs.washington.edu (Scott MacHaffie) writes:
< > 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).
> 
> This is specious. Assume break and if; then while, do, for, and loop
> are all equivalent, in the sense that each can be written purely
> syntactically in terms of any of the others. Therefore (in line with
> the goals of the language, to evolve in another thread) the simplest
> construction wins. (There are several criteria for choosing ``loop''
> as the simplest; but I don't think anyone will argue, so I won't
> elaborate further.)

This is correct but bad.  Any machine can be simulated in a small 
universal Turing machine with few states, but the operations will
run very slowly.  Also, there are situations where anything other
than goto is very inefficient.  Another one omitted is a "break to
stage ..." which may close several blocks at once.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)