Languages with C-like syntax get else if
for free without having to implement it at all.
The reason is that in that syntax control structures simply operate on the next statement, which can be a compound statement enclosed in braces if necessary (e.g. { x += 1; y += 1 }
).
This means that once you've implemented if
and else
, else if
just falls out of the grammar of the language naturally for free, with no further implementation effort. To see why, have a look at this:
if (condition) {
if_body();
} else if (another_condition) {
else_if_body();
} else {
else_body();
}
This looks like an if
with an else if
and an else
attached, each applied to a compound statement. But in fact it's not. This is actually two separate if
statements, each with exactly one else
case; the second if
statement is inside the body of the else
of the first if
statement.
else if { ... }
is really parsed as else
applied to the next statement, which is an if
statement (applied to the compound statement { else_if_body(); }
. Then the final else
binds to the immediately preceding if
, which is the second one.
Here's the same thing written more in line with how it's parsed1:
if (condition) {
if_body();
} else {
if (another_condition) {
else_if_body();
} else {
else_body();
}
}
But it turns out that if the language did directly implement else if
as a first-class option for if
statements, it would behave exactly the same as the second independent if
statement inside the else
of the first! So there's no need to bother implementing else if
at all; language implementers get else if
for free with this style of syntax, once they've implemented if
and else
.
Python's syntax doesn't allow this freebie.
Programmers of C-style syntax can think in terms of else if
even though the language only has if
with exactly zero-or-one else
, but only because they can write code like my first example that is formatted in a way that looks different to a human reader than it does to the compiler.
Python, OTOH, uses indentation to indicate block structure, which forces the block structure to look the same to a human reader as it does to the interpreter2. Once you've got if
and else
in Python-style syntax, programmers could still write code that behaves identically to an else-if, by putting a second if
statement inside the else
of a first. But that comes out looking like this:
if condition:
if_body()
else:
if another_condition:
else_if_body()
else:
else_body()
This looks ugly, and is much more complex to think in terms of than an else-if chain once you get more than 1 or 2 else-ifs. So it's worth adding in an explicit language feature to get back the ability to think in terms of else-if. Even though it technically makes the language more complex, it actually makes thinking in terms of the language simpler, so it's good complexity; with a manually constructed chain of nested if
s inside else
s the reader has to manually read all the code and verify that every else
except the last contains exactly one if
statement and nothing else, in order to conclude that the whole sequence is equivalent to a linear chain of conditions checked in order, with some code to execute for the first check that succeeds.
So then. We've seen that languages with C-like syntax might as well go with else if
, because they get it for free. That's the reason why that exists. Languages with Python-like syntax have to explicitly do something to get a construct that can be used as an else-if. Why did they choose elif
? It's arbitrary; you'd have to actually ask the people who made the decision.
However Python didn't invent elif
, it was around in other languages long before Python existed. So I would guess that when they had to implement an explicit else-if construct they simply picked one that programmers were already familiar with.
1 Technically, this is how people who are REALLY serious about always using braces with control structures should write their code. ;)
2 You can certainly construct counter-examples to this, but it's the general idea of indentation-based syntax.