# Philosophical discussion of Elif, Elsif, ElseIf

**URL:** https://discourse.julialang.org/t/philosophical-discussion-of-elif-elsif-elseif/42885
**Category:** Meta Discussion
**Created:** [July 11, 2020, 5:54am UTC](https://discourse.julialang.org/t/philosophical-discussion-of-elif-elsif-elseif/42885 "2020-07-11T05:54:39Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![Bryan\_So](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bryan_so/32/16228_2.png) [@Bryan\_So](https://discourse.julialang.org/u/Bryan_So)
#### Post date: [July 11, 2020, 5:54am UTC](https://discourse.julialang.org/t/philosophical-discussion-of-elif-elsif-elseif/42885/1 "2020-07-11T05:54:39Z")

</div>

Most languages define ElseIf as a keyword. It makes no sense to me.

Julia:

```julia
if <condition>
    ...
elseif <condition>
    ...
else
    ...
end

```

Python:

```julia
if <condition>:
    ...
elif <condition>:
    ...
else:
    ...
end

```

Bash elif; Ruby elsif; Euphoria elsif; … etc

This has NO advantage in human readability (elsif, elif, elseif are all not in a dictionary). I don’t think the compiler does better optimization with them either.

The following differs from “elseif” in one single space:

```julia
if <condition>
    ...
else if <condition>
    ...
else
    ...
end

```

Why?

---

<div class="post-metadata">

### Author: ![Keno](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/keno/32/285_2.png) [@Keno](https://discourse.julialang.org/u/Keno)
#### Post date: [July 11, 2020, 6:00am UTC](https://discourse.julialang.org/t/philosophical-discussion-of-elif-elsif-elseif/42885/2 "2020-07-11T06:00:42Z")

</div>

The standard answer is that in languages like julia, certain keywords like `if` introduce a block while others like `else` and `else if` continue a block. As a result `else if` would require an extra `end` by regularity (also to avoid confusion if you really did want an if block inside your else block). Of course that doesn’t apply to languages that do scoping differently and indeed in e.g. C you’d spell it `else if`. Python doesn’t really need it either, but as with all things python who knows why it works the way it does.

---

<div class="post-metadata">

### Author: ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [July 11, 2020, 12:54pm UTC](https://discourse.julialang.org/t/philosophical-discussion-of-elif-elsif-elseif/42885/3 "2020-07-11T12:54:05Z")

</div>

Even in languages like C where you can just do `else if` there’s a famous parsing ambiguity due to this construction:

> **[Dangling else](https://en.wikipedia.org/wiki/Dangling_else)**
>
> The dangling else is a problem in programming of parser generators in which an optional else clause in an if–then(–else) statement results in nested conditionals being ambiguous. Formally, the reference context-free grammar of the language is ambiguous, meaning there is more than one correct parse tree.
> In many programming languages one may write conditionally executed code in two forms: the if-then form, and the if-then-else form – the else clause is optional:
> This gives rise to an ambiguity i...

---

<div class="post-metadata">

### Author: ![Bryan\_So](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bryan_so/32/16228_2.png) [@Bryan\_So](https://discourse.julialang.org/u/Bryan_So)
#### Post date: [July 12, 2020, 7:10pm UTC](https://discourse.julialang.org/t/philosophical-discussion-of-elif-elsif-elseif/42885/4 "2020-07-12T19:10:36Z")

</div>

Thank you!