Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!mips!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: <191@gollum.twg.com>
Date: 2 Mar 90 22:02:28 GMT
References: <22569:05:10:24@stealth.acf.nyu.edu> <8475@wpi.wpi.edu> <24123:04:14:07@stealth.acf.nyu.edu> <1966@l.cc.purdue.edu>
Organization: The Wollongong Group, Palo Alto, CA
Lines: 73

In article <1966@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

>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.

An idea I find attractive (I'm weird), is to delimit loops with statements
in the following kind of way:

        label: loop while (top_break_condition);
          .
          .
          .
               exit label if (middle_break_condition);
          .
          .
          .
        repeat label while (bottom_break_condition);

The "label" is a normal kind of statement label (although there is as case
for prohibiting a goto the label on a loop statement).  Also, the label and
label references may be omitted, defaulting to the "innermost" case.  The
"while" and "if" (and any other allowed forms such as "for," "unless," ...)
are all optional.

I like this because it ties together all the looping forms into a single
concept at the language level.  It also gives you a consistent way to show
if the exit test is done at the beginning of each iteration, or after, or
both, or neither, or something else.  It even allows unambiguous partial
overlapping of loops, especially if you can do a similar bracketing of the
if-else construct.

In fact, I strongly suspect (but cannot prove) that such "if-else" and
"loop" constructs, taken together, have exactly the same expressive power
as "goto" combined with the simplest "if."  In other words, a compiler
would have no difficulty generating just as efficient code either way.
This is because "loop-repeat" is fundamentally an unconditional goto
backwards in the control flow from "repeat" to "loop" (with provisions
for jumping or continuing forward to the statement following "repeat"),
and "if-else" provides for conditionally jumping in the forward direction.  
The only thing this doesn't seem to cover is jumping over completely dead
code, or jumping to-from a piece of code which is logically but not
physically sequential (and I don't mean a subroutine/function call).
Neither of those cases are "efficient" or "useful" in anything but a
bizarre context.

I should point out that I don't see how to express this idea in a syntax
form that meshes well with C.  It seems a bit wordy for C and goes
counter to C's statement-within-statement approach to things.  C would
also use "break" instead of "exit;" this produces vivid mental images
of "broken loops"!  Seems OK for Fortran, though.

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