Re: break/continue vs. try-always

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Fri, 06 Jun 2014 23:22:50 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> I don't understand what "return -r" would do.

This would allow a sandbox inside a function; otherwise you couldn't
prevent the user skipping out early, and if you can't put a sandbox
inside a function the whole concept is degraded in a fairly major way.

I notice, however, that "return -r" is currently not an error.  That's
because it's "return $(( - $r ))", which is entirely valid for zsh (but
not other shells), even though a negative status isn't valid.  That
slightly gums up the normal option parsing in any case, but it looks
like it's long-standing behaviour:

% r=-1
% fn() { return -r; }
% fn
% print $?
1

So we need a syntax plan B.  Variables are possible --- we already do
stuff with TRY_BLOCK_ERROR, and the code I have working is likewise
specific to "always" blocks.

Anyway, actual functioning code with a change made before I noticed that:


% which fn
fn () {
        {
                print Before return.
                return
                print After return.
        } always {
                print In always block.
                return -r
        }
        print Evil plan by user to return early defeated.
}
% fn
Before return.
In always block.
Evil plan by user to return early defeated.


Hmm... along the lines of TRY_BLOCK_ERROR, and as negative numbers
aren't useful... how about... TRY_BLOCK_RETURN is by default negative,
but gets set to >= 0 if user signals a return; "always" block can set it
to some other value, one option would be to negative to prevent the return...?  This also means you can force a return from the end of the always block.


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

Yes, indeed.  The minutiae of the standard may or may not be of some
help.

-- 
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/