From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28589 invoked by alias); 8 Jun 2014 18:01:12 -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: 32747 Received: (qmail 937 invoked from network); 8 Jun 2014 18:01:08 -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 X-Originating-IP: [86.6.157.246] X-Spam: 0 X-Authority: v=2.1 cv=f8XGBYCM c=1 sm=1 tr=0 a=BvYiZ/UW0Fmn8Wufq9dPrg==:117 a=BvYiZ/UW0Fmn8Wufq9dPrg==:17 a=NLZqzBF-AAAA:8 a=LGXc4NIGxrIA:10 a=uObrxnre4hsA:10 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=Jv2evalZxEBIIK3praMA:9 a=CjuIK1q_8ugA:10 a=I6wTmPyJxzYA:10 a=_dQi-Dcv4p4A:10 Date: Sun, 8 Jun 2014 18:54:01 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: break/continue vs. try-always Message-ID: <20140608185401.35bed78f@pws-pc.ntlworld.com> In-Reply-To: <140606232250.ZM23057@torch.brasslantern.com> 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> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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. 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 Web page now at http://homepage.ntlworld.com/p.w.stephenson/