On Mon, 13 Aug 2018, Riccardo (Jack) Lucchetti wrote:
On Mon, 13 Aug 2018, Allin Cottrell wrote:
> You can create ... a "backwards" loop at present, either using
> the more flexible (but more cumbersome) "for" construct or by
> adding an auxiliary index, but it would be convenient to have the
> decrement case handled automatically.
[ and Allin adds: if so, probably only in response to a --decrement
option to "loop" ]
Given the potential for breakage, I'm not a great fan of the
--decrement option, especially considering that the alternative is
relatively painless in all the examples I can think of.
I don't want to flog this to death, but just a couple more comments.
1) Having "loop i=start..stop" decrement its index when stop is less
than start, unconditionally, is definitely a non-starter in terms of
backward compatibility. It breaks seven of the current function
packages.
2) So the only (possibly) live option is having this happen in
response to a new --decrement option. And to avoid ambiguity, I
think this option should produce the mirror-image of present
behavior: so iteration would be skipped if stop > start.
Would that be worthwhile? I'm not sure, though I tend to think the
transparency of a decrementing index loop would be nice. Jack speaks
of "potential for breakage": that's surely true if decrementing were
implemented unconditionally, but not if it depends on an option
flag. IMO the question is whether a new option would be redundant,
given what can already be done using an auxiliary variable (which
goes down as the loop-index goes up).
Anyway, if I don't get any substantial support for this notion I'll
quietly give it up.
Allin