Re: PATCH: `try' syntax

[Bart Schaefer <schaefer@xxxxxxxxxxx>]

On Tue, 15 Jun 2004, Oliver Kiddle wrote:

> Bart wrote:
> > * 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.)
> 
> That would be quite a good way of handling it. My main reservation
> concerns the fact that it isn't possible to make the enabled/disabled
> state of builtins local.

Hmm, good point.  You'd have to do something like

	enable try always tried
	try
          # ...
        always
	  disable try always tried
        tried

(which should work, because the entire "try ... tried" must be parsed
before the disable executes), but one would also have to store the initial
state of the keywords and then test whether to disable them.

> Consider _approximate. It'd be nice to use a try/always block to do the
> job currently performed by a trap to unfunction compadd. So how do you
> enable try and always but restore their original state when completion
> exits.

Maybe the "enable" command should have a -L option like "emulate", that
works like "setopt localoptions".  There could even be an option for it,
"localenable".  (This begs the question of whether "localdisable" is a
synonym or ...)

> It's possible using the parameters module but would get fairly messy.

Hmm ... wouldn't

	local -a +h reswords dis_reswords

cover all possible cases?  (Hmm, again; no, it seems it does not, because
either the values aren't restored and/or assigning to these arrays doesn't
accomplish enable/disable.  Odd, but oh, well.)

On Tue, 15 Jun 2004, Peter Stephenson wrote:

> Bart Schaefer wrote:
> > * A "shortloops" form "try { ... }" might be nice, or maybe should be the
> > only form.
> 
> It's rather nonstandard.

So is the whole "try" concept, at least for shells.

> Oliver wrote:
> > Or, thinking along those lines, you could use something like
> > { ... } always { ... }
> > That currently finds a syntax error at always.
> 
> Syntactically, it's still a bit tricky.  Either `always' is a keyword,
> or it isn't.

Not unprecedented; "in" behaves like a keyword in certain positions, but
is not one.

> The other part is that we don't know till we get to the `always'
> whether there is an always present.  Possibly it could just be
> tacked onto ordinary current-shell structures.

In the case of "in" there's always an introducer ("case", "for", etc.),
which would argue for leaving the "try" somewhere.

On a different tangent, maybe the whole thing should parse more like
"coproc" does, and perhaps "always" should be replaced with something
like the ";&" from "case".

> As things stand I'm not sure I'm going to have any free time before
> 2008, but if I do is this worth trying?  (In other words, is it
> reasonably agreeable to everyone interested?)

It's definitely getting close.