You can, yes. However, doing that requires making the newline between the `else` and `if` significant:
if c1 then
s1
else
if c2 then
s2
else
s3
end
end // <-- Two "end"s
Versus:
if c1 then
s1
else if c2 then
s2
end // <-- Only one "end"
If you don't make the newline there significant, then every if statement at the beginning of an else clause would be interpreted as chained:
if c1 then
s1
else
if c2 then
s2
end
s3
end
Here, the parser will incorrectly treat the first "end" as closing the outer "if" when it's intended to close the inner one. It will then think "s3" is outside of the "else" clause and then consider the second "end" to be a parse error.
In principle, this isn't actually ambiguous and if the parser had unbounded lookahead it could probably find the second "end" and rollback and figure out what's going on. In practice, languages with unbounded lookahead are hard for humans to parse too.
Having an explicit "elif" token avoids all of this weirdness.
Why are people upvoting this as if it wasn't just explained why that's not true? That's only possible when you have (mandatory) block delimiters. That was the entire basis of the comment—that `elif` is used in "languages that don't have an explicit block statement with its own delimiters".
Are INDENT and DEDENT here describing whitespace sensitivity in the vein of Python, which "uses whitespace to delimit control flow blocks"[1] (elsewhere[2]: "Python uses whitespace indentation, rather than curly brackets or keywords, to delimit blocks")?
We're specifically talking about the subset of languages where these blocks _don't_ have their own delimiters[3].
3. There is a reading of Bob's original comment such that it's suggesting that Python and end-if languages are among languages without them (or something—I can't make total sense of that part of the comment; it gets kind of garden path-y), but they're not.
