Re: PATCH: `try' syntax

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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