Re: break/continue vs. try-always

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 6, 10:45pm, Peter Stephenson wrote:
}
} On Fri, 6 Jun 2014 14:08:53 -0700
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > On Jun 6, 2014 2:04 PM, "Peter Stephenson" <p.w.stephenson@xxxxxxxxxxxx>
} > wrote:
} > 
} > I was thinking perhaps "break 0" which is otherwise/currently an error.
} 
} That's straightforward --- well, it isn't, but it's straightforward to
} make it only work in always blocks and ignore it elsewhere which is
} probably good enough since this is rather a specialised feature --- but
} it occurred to me that for a complete sandbox it would be useful to have
} "continue -r" and "return -r".

I don't understand what "return -r" would do.  Unlike "break 1000" for
example, and except for the weird case of 'trap return EXIT', "return"
can't affect anything beyond the local scope.  E.g., where one might
do

    outer() {
      while (($#)); do { inner $1; shift } always { break 0 }; done
    }

to prevent inner from stopping the loop in outer, I don't see any case
in which the always block would need to cancel a return.

} Actually, break -r (or break 0) would have a side
} effect on continue because of the interaction between the "breaks" and
} "contflag" variables, so arguably break -r and continue -r shouldn't be
} independent however it's implemented.

There may already be a conflict there, e.g.

  while print one; do
    while print two; do
      while print three; do
	  { break 2 } always { continue 3 }
      done
    done
  done

In fact if there are both a "break" and a "continue" in the try-always,
the effect is as if "continue" were called with the larger loop count,
no matter which of them appears in the try vs. the always blocks.

So we should probably define those semantics before we figure out what
a value of 0 (or whatever) means.