Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!amdahl!twg.com!dwh
From: dwh@twg.com (Dave W. Hamaker)
Newsgroups: comp.lang.misc
Subject: Re: Anyone want to design a language?
Message-ID: <212@gollum.twg.com>
Date: 16 Mar 90 22:45:48 GMT
References: <22569:05:10:24@stealth.acf.nyu.edu> <8475@wpi.wpi.edu> <4489:05:14:19@stealth.acf.nyu.edu> <10790@june.cs.washington.edu>
Distribution: usa
Organization: The Wollongong Group, Palo Alto, CA
Lines: 35

machaffi@fred.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).
>
>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.

I like the loop syntax:

<optional label:> loop <optional control clause>
                  .
                  .
                  .
                  repeat <optional label reference> <optional control clause>

And I suggest compilers should issue a warning for multi-exit loops.  In that
case, you only need to examine multi-exit loops in detail.  Otherwise, you
look for an exit condition in the control clause at the top; if not there,
look for it at the bottom; otherwise locate it inside.  Use of loop label
references handles extra "repeat" statements, as well as multi-level exits.

Does this approach mitigate the "serious problem"?

I especially like the way _all_ loops become variations of a single form
at the language level.  I believe this would improve thinking about loops
overall.

-Dave Hamaker
dwh@twg.com
...!sun!amdahl!twg-ap!dwh