Re: proposed features for branching logic + minimal implementation

[Liam Quinlan]

Wow.

Ok, so this is embarrassing (and i can't now find the section of
documentation where I was sure I'd read this)... but I actually made this
suggestion while under the impression that the label for a branch command
must proceed the branch command itself.  ie, that there was no forward
branching.  Checking this now, that does not seem to be the case.

So, oops.  I could have sworn I'd tried in the past and got an error, too...


If others like the syntax i suppose it may still have merit on those
grounds (the curlies do make it feel like an if block), but I didn't
realize I was asking for something we already had.


On Tue, Oct 13, 2020, 13:38 Nora Platiel, <nplatiel@gmx.us> wrote:

> > At first scan, especially focusing on possible code paths, encountering
> > 'Tn' causes me to look for the 'n' label in order to understand where
> it's
> > going... and in a sense, 's/^//;Tn' lies about that. Hence, "put the
> label
> > next to it" became my preferred tactic.
>
> I was suggesting the use of 's/^//;T;', not 's/^//;Tn;', since you
> mentioned "hunting around the keyboard for label names". But you may still
> find ':n;tn;' easier to read.
>
> I agree that both ':n;tn;' and 's/^//;T;' are kludgy and ugly, and I
> wouldn't want to use them. Under this proposal you could also use '@{}'
> (empty group of commands) to reset the flag.
>
> To summarize (correct me if I got something wrong):
>
> @{...}          -> TL; ...; :L
> @!{...}         -> tL; ...; :L
> k               -> tL;s/^//;:L
> j = J;k = @{};k -> s/^//
> J = j;k = @{}   -> :L;tL = s/^//;T
>
> The @ address makes more sense to me than the t/T commands themselves: an
> address is a more natural and expressive way to test for a condition.
> Under this proposal, t/T would become syntactic sugar:
> t -> @b
> T -> @!b
>
> More importantly, the single forward branch pattern comes up often enough
> in my scripts, and the @ address would greatly improve readability and
> simplify label management.
> +1 for the @ address!
>
> About J/j/k, I'm not sure how useful they are for general purposes, I
> would have to experiment. Perhaps the maintainers would like to see some
> concrete real world example for J/j/k.
>
>