control structures (was "Re: Sins")

[Steve Holden]

Phil Jensen wrote:

> [...] 
> I forget if I posted this before, but what I'd like to
> see is the Zahn construct discussed in Knuth's article -
> Pythonically:
> 
>     loop until "element found" or "search failed":
>         ...
>         if blah1 == blah2:
>             "element found"
>         ...
>     when "element found":
>         ...
>     when "search failed":
>         ...

A common Pascal idiom, I seem to remember, could be Pythonically
expressed as something like:

    loopstate = "searching"
    while loopstate = "searching":
        ...
	if bah1 == blah2:
            loopstate = "found"
        elif <out of elements>:
            loopstate = "not found"
        else:
            <move on to next element>

Typically one would use enumerations rather that strings to
represent the loop states, to combine readability with efficiency.

> 
> Whatever the loop is, its exit or exits have some "meaning"
> in the program, and this control structure encourages an
> element of Literacy by forcing them to be named.
> 
One of the annoying features of the staement/expression dichotomy
is that one cannot return a value from a loop.  In Icon, for example,
everything is an expression, and so a loop returned the value of the
last expressions evaluated inside.  This made it easier to detect
different loop termination conditions.

> [...]
> 
> IMHO, "break 3" would be awful.
> 
I agree.  Again, the Icon "break" took an argument which was returned
as the value of the loop, and so it was possible to write

	break break break

to exit from three levels of looping.  However, given our propensity
to change code by adding additional iterative contexts, this would be
little better than "break 3" in terms of preserving semantics across
such modifications, and nowhere near as helpful as labelled breaks.

But, how to put the labels in?

regards
 Steve