From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21177 invoked by alias); 8 Jun 2014 18:41:41 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32748 Received: (qmail 9259 invoked from network); 8 Jun 2014 18:41:28 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140608114123.ZM20229@torch.brasslantern.com> Date: Sun, 08 Jun 2014 11:41:23 -0700 In-reply-to: <20140608185401.35bed78f@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: break/continue vs. try-always" (Jun 8, 6:54pm) References: <140603191227.ZM28198@torch.brasslantern.com> <140604223723.ZM22960@torch.brasslantern.com> <140605085319.ZM4272@torch.brasslantern.com> <20140606215853.0c6ecae9@pws-pc.ntlworld.com> <20140606224523.09d5f22c@pws-pc.ntlworld.com> <140606232250.ZM23057@torch.brasslantern.com> <20140608185401.35bed78f@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: break/continue vs. try-always MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jun 8, 6:54pm, Peter Stephenson wrote: > > On Fri, 06 Jun 2014 23:22:50 -0700 > Bart Schaefer 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. Sorry, I'm still not getting it. The point of being able to reset a break/continue is because you might have fn_that_I_wrote() { while some_test_of_mine; do { fn_somebody_else_wrote_that_calls_break_1000 } always { print dammit there should be some way not to break here } done } In the case of "return", there is no such situation, again unless you are considering "trap return EXIT" in which case fn_that_I_wrote() { (){ douchebag_fn_that_calls_return_in_EXIT_trap } "$@" } is already sufficient. Which you can also use for a sandbox, no? Under what circumstances would I need to use try-always to cancel my own evil return? } 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. Yes, when I first encounterd this I was expecting TRY_BLOCK_ERROR to be the solution, until I realized that continue was not an error. } 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. It would generally be useful to know how/why one arrived in the always block, along the lines of emulating throw/catch ... but again you can already force a return from the end of the always block with "return" itself, so I'm not sure a return-specific variable is the right thing. } > 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. } } Yes, indeed. The minutiae of the standard may or may not be of some } help. It might, but I sort of doubt it, as try-always is not standard; there is no standard way to switch from breaking to continuing. I suppose whichever of them is going to affect the larger number of loops should win. E.g. if you do "continue 4" while 6 levels deep and then two levels up (so effectively at "continue 2") the always block asserts "break 3" then break wins. Ties ... go to whichever was called most recently?