Re: break/continue vs. try-always

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 8,  8:43pm, Peter Stephenson wrote:
} Subject: Re: break/continue vs. try-always
}
} On Sun, 08 Jun 2014 11:41:23 -0700
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > Sorry, I'm still not getting it.
} >...
} > Under what circumstances would I need to use try-always to cancel
} > my own evil return?
} 
} I'm not really getting you're not getting it.  Why does it have to be
} your own return? Isn't the point of a sandbox to prevent something you
} *don't* control?

Because return respects function scopes, there are extremely limited
circumstances under which it would not be my own return.  I'm trying to
understand exactly when you feel a return would not be under the control
of the same person who is writing the function.

} However, what *I'm* missing is that break and continue propagate outside
} a function --- so you can't trap them that way anyway.

This and exactly this is the only problem that I'm trying to solve with
this thread, which is probably how we got out of sync.

} If you like the idea of function scope as a sandbox, it seems me that a
} neater way to handle this would be to add an option to force break and
} continue to respect function scope.

The problem with that solution is that it propagates downward -- it's
the inverse of break/continue propagating upward.  There may be layers
of function scope in between the caller and the eventual break/continue
that expect the current dynamic-scope behavior.

} setopt localoptions localloops
} () {
}    # call user code
} }
} # localloops is restored on return here and used to cancel breaks /
} # contflag before resuming user code at this point.
} 
} e basta.  That's also very simple to implement, with no new globals or
} variables, and the only namespace affected is one we have complete
} control over.

Yes, in fact I already implemented it (see the background discussion in
workers/32693) but I don't like it much, for the reason above.