Why do many template languages have `for-else` statements?

Question

I've noticed that many template engines have a mechanism for detecting that a loop is not occurring.

Although their names and syntax vary, they all have this similar structure.

For example:

• Jinja

{% for user in users %}
    {{ user }}
{% else %}
    This is only evaluated if `users` is empty
{% endfor %}

• Jade

- var users = [];
ul
  each user in users 
    li= val
  else
    li This is only evaluated if `users` is empty

• Hugo

{{ range $users }}
    {{ . }}
{{ else }}
    This is only evaluated if $users is empty
{{ end }}

But I have hardly seen similar constructs in general-purpose programming languages.

_{Notice: Python does not have this structure, these languages implement no-run detection, while python implements no-break detection.}

What causes the disagreement between template language authors and general-purpose language authors?

Answer 1

Template languages tend to format a document to show to a human, when doing a foreach on a set you are likely outputting a list of results.

It is good UX to have a explicit message when there are no results to show rather than to show nothing (which can look like a bug).

So there is high demand for a default handling of the zero count loop,

Whereas in imperative languages doing a loop means accumulating a result. An empty set will result in the initial value of the accumulator. You need that initial value anyway to initialize it and that starting value is often good enough as the result.

Answer 2

For exactly the same reason that most imperative programming languages that do iteration with for loops accept an empty collection to iterate over instead of throwing an error. It’s a very common case to need to account for, and it also is much easier to read if you don’t need the check for an empty collection.

Similarly, the general construct you show in your examples of doing something different if a collection of items is empty is a very common need when doing presentational templating (which accounts for a vast majority of template language usage), and it’s much easier to read a for/else syntax than it is to read an if/for/else construct.

Using Jinja as a point of comparison, here’s what that example would look like without for/else syntax:

{% if users|length > 0 %}
    {% for user in users %}
        {{ user }}
    {% endfor %}
{% else %}
    This is only evaluated if `users` is empty
{% endif %}

It’s not horrible, but there’s a lot more template language in there than in the for/else case, which is less than ideal especially given that this type of thing is likely to show up very frequently if you’re rendering things that users will be seeing.

Answer 3

I believe this is because general purpose PLs have been conservative, especially around syntax and reserved words, and they had no chance to absorb these highly useful ideas from template languages, which are newcomers to this landscape and prioritize convenience over tradition.

C had three-section for loop which influenced a lot of languages and which allowed for fine tuning of looping conditions, which almost nobody used.

Java used "smart for-loop" which Steve Yegge called "dumb for-loop" because you could do even less things with it than with traditional for-loop. Unfortunately, it did not catch further, and now you have better chances of seeing functional programming / Java streams / LINQ rather than any innovative structured programming constructs.

If you would be designing a programming language from scratch, of course you will have a way to iterate a collection, and it will have the ability to

• Determine whether current item is first/last item being iterated.
• Remove current item from collection being iterated.
• Run an auxiliary code block when the collection was empty (that's what this question is about).

I'm placing some hopes on Kotlin which has rich syntax already.

Answer 4

Poor composition

Template languages tend to be less complex, and by so, care less for composition problems.

But a else clause in loops compose baldy with ifs:

if cond
each user in users 
  { ... }
else
  { ... } // of each, possibly empty, to guarantee that
else
  { ... } // this else, of if, is reachable.

On languages with named end delimitador this is a lesser problem (the Jinja example).

But in languages with with fixed or implied block end delimitation, this may cause a variation of dangling else problem.