[erlang-questions] Erlang elseif

[Richard O'Keefe]

On 21 Nov 2008, at 8:37 pm, Daniel Rönnqvist wrote:

> I am merely trying to figure out why this simple logical control  
> structure don't exist;
>
> If <expression> == true then <expression>
> elseif <expression> then <expression>
> else <expression>

Because Erlang does not have a Boolean data type.

No, seriously.

Erlang was and is based firmly on
  - function call
  - case
Originally, type tests and comparisons were guards only,
not expressions.  They did not return 'true' or 'false',
so there never were any expressions that _could_ be used
to control 'if' expressions.

'if' was introduced as an abbreviation for a 'case'
with trivial matching.

Then the Great Blunder occurred:  the type tests and comparisons
were duplicated, and as well as the guard versions there were
expression versions, returning 'true' and 'false'.  This was
compounded by the addition of far too many operators, both
'and' *and* 'andalso', both 'or' *and* 'orelse'.

This immediately created pressure to make Erlang stop being
Erlang and turn it into something else.  In particular, some
people want to allow arbitrary expressions as guards (with all
the questions that raises about "what sense does it make to
have a side effect that happened in a clause that wasn't selected")
and that would have as a consequence that 'if' would be much
closer to what you want.
>
>
> I know I can get lots and lots of good ideas on how to do this if I  
> were to give you my whole real example but that is not my point. I  
> am narrowing it down to this because THIS is what I want to discuss.

But you are now refusing to discuss a key reason why the
present (or rather, the pre-Great Blunder) state of affairs
is a Good Thing.

It's not just "good ideas" you might get if we saw a real example,
it's BETTER ideas than using a C-like 'if'.
>
>
> IMHO, it shouldn't be that hard for the compiler/precompiler to  
> "rewrite" another control structure as nested case statements which  
> would work as a general solution, be very fast with less and  
> arguably more readable code.

There is no reason to expect it to be 'very fast' compared with 'case'.
Any situation that was faster as an 'if' than as a 'case' would
count as a performance bug in the compilation of 'case'.

"Arguably more readable code" evades the question of "readable to whom?"
I don't know any reason why coding using C-like 'if' should be
more readable to proficient Erlang programmers than other ways of
writing the same thing.  Past experience leads me strongly to doubt it.


Note that I am not saying that C-like if is bad.
Partly, I suppose that I am saying that insisting that everything
be like everything else is no way to explore and learn and maybe
learn better.

The situation post Great Blunder is unstable.
Having nibbled at the 'logical expression' forbidden fruit,
Erlang should either vomit it out or gulp down the whole
poisoned apple.

For the micro-Erlang design I'm playing with, I chose the
"vomit it out" route.  Back to the future.  Less is more.
It's amazing how little 'logical expressions' are missed if
you seriously try to think without them.

For real Erlang/OTP, backwards compatibility puts backwards
pointing spikes on the poisoned apple; it's hard to vomit it
out without ripping out your throat.  Erlang/OTP may have to
gulp down the _whole_ thing and just hope that people don't
do silly things, like CAML and SML.