So one of the common responses/objections is that the existing list widget is a perfectly good and already very easy way of doing loops (which is true) and therefore that new syntax for it doesn’t really add much value.
The only difference between this sort of proposed “for loop” and the “conditional/if” would be the removal in the generated list widget (in the parse tree) of “limit=1” (and “variable=condition” - removed entirely in foreach, and replaced with a different variable name in for foo in [...]). This is part of what made the idea appealing to me; I have sometimes thought, “The thing I want to do is almost exactly the same as the “if”, so why do I need to write completely different syntax for it?”
But I realized that the similarity of the widget (parse tree) implementation–the fact that conditionals and loops are just slight variants on the same thing (even the <% if %> is just syntactic sugar for a <$list> as @pmario pointed out)–would actually allow a structure unique to TiddlyWiki. If you can change a keyword to determine whether you loop or only render once, then you could extend that idea to “elseif” by introducing “else-for” (and “else-foreach”) when you want to change an “elseif” to a loop. You could even mix them:
<% if [filter] %>
some stuff
<% else-for egg in [tag[spam]] %>
if the condition is not true, we process *each* egg
<% elseif [some other condition] %>
Something to do if some other condition is true, only if there are no eggs in spam
<% else %>
If all else fails...
<% endif %>
Each “elseif” or “elsefor” block is just a $list widget (with slightly different attributes, most importantly the presence or absence of limit="1") inside of the $list-empty of the previous block.
One potential downside to this is that it would pose a challenge to the use of empty instead of else for loops. I think the strength of this sort of construction is in utilizing the fact that both “if” and “for” are basically the same thing and treating them as such, but in treating them as such, it would be hard to then say you have to use “empty” with “for” and “else” with “if”, and in mixing them, it would get confusing (do you need “empty-if” and “empty-for”???). Part of the benefit of the idea is being able to change just one key word in order to switch between looping and not looping, but requiring empty for loops and else for conditionals would make you change two keywords in two different places if you wanted to change from a loop to a conditional or vice versa.
Perhaps one way to mitigate that would be to simply let “else” and “empty” be interchangeable, both valid keywords in both loops and conditionals, with the expectation that most people are going to use the word that semantically makes most sense to them (which will usually be “else” in conditionals and “empty” in loops - though the code won’t break if you change a conditional to a loop or vice versa and forget to change the else/empty part). This would allow “for” to be taught/documented with examples using “empty” rather than “else”, and then we could have a separate page in the documentation for nesting and mixing with for loops.
