From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8245 invoked from network); 14 Jun 2004 18:25:16 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.86) by ns1.primenet.com.au with SMTP; 14 Jun 2004 18:25:16 -0000 Received: (qmail 27102 invoked from network); 14 Jun 2004 18:23:42 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Jun 2004 18:23:42 -0000 Received: (qmail 15068 invoked by alias); 14 Jun 2004 18:23:37 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20048 Received: (qmail 15000 invoked from network); 14 Jun 2004 18:23:35 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 14 Jun 2004 18:23:32 -0000 Received: (qmail 19718 invoked from network); 14 Jun 2004 18:14:51 -0000 Received: from moonbase.zanshin.com (root@64.84.47.139) by a.mx.sunsite.dk with SMTP; 14 Jun 2004 18:14:50 -0000 Received: from toltec.zanshin.com (toltec.zanshin.com [64.84.47.166]) by moonbase.zanshin.com (8.12.11/8.12.11) with ESMTP id i5EIEmXs024383 for ; Mon, 14 Jun 2004 11:14:48 -0700 Date: Mon, 14 Jun 2004 11:14:47 -0700 (PDT) From: Bart Schaefer Sender: schaefer@toltec.zanshin.com Reply-To: Zsh hackers list To: Zsh hackers list Subject: Re: PATCH: `try' syntax In-Reply-To: <29441.1087232105@trentino.logica.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 On Mon, 14 Jun 2004, Peter Stephenson wrote: > Here's an experimental and possibly controversial (though, I think, > working) new syntax for running code protected from error and other > conditions in an internal block. [...] > > The trickiest bit is the naming. I wanted something reasonably > memorable, but without polluting the name space, hence the names > with the colons in front. I have several suggestions, in no particular order (and I'm deleting the ones that overlap with Oliver as I find them). * I'm not thrilled with "try" and "always" but I haven't yet come up with anything better. * A "shortloops" form "try { ... }" might be nice, or maybe should be the only form. * How about making this work with any loop body by replacing "do" with "try"? Then get rid of "try" as a standalone reserved word and instead use "repeat 1; try ... always ... done" * Rather than putting colons or some other unlikely character in front of the name, use plain words and start with them "disable"d, so that in order to use this syntax one must first "enable -r try always tried". (This technique could apply to other extension syntax as well.) * Tangential thought: Is it really necessary to disable e.g. both "case" and "esac" or is it sufficient to disable (and enable) "case"? On Mon, 14 Jun 2004, Peter Stephenson wrote: > Oliver Kiddle wrote: > > It could be useful to > > have something like the errexit and errreturn options apply within the > > try block. > > They do, but to the enclosing function (the always block would be > executed). So does that mean that :try setopt errexit false print not reached 1 :always print reached :tried print not reached 2 prints only "reached"? Then that's a non-obvious way to accomplish what Oliver wanted: > > It'd be really useful to have a way to skip over the rest of the try > > block, going straight to the always code. On Mon, 14 Jun 2004, Oliver Kiddle wrote: > TRY_ERROR sounds fine though I might go for TRY_STATUS > > > (I wonder if it could be setable inside the try block to force errflag > > to 1, forcing the rest of the block to be skipped? [...]) > > That's an interesting idea. Would be useful. Having a variable > assignment affect control flow would be more than a bit weird, though. I agree that it would be weird. Another new keyword would be better (see my suggestion about starting disabled).