[erlang-questions] Erlang elseif

[Daniel Rönnqvist]

I mistakely sent my last answer privately, here it goes again (with
additions):

Richard, I understand and to a great extent agree with your will to stay in
the functional language domain and don't adapt to much other paradigms. All
I'm saying is that theoretically it can be inefficient to have to run _all_
tests (expressions), tag the results and then pattern match on this tag,
especially when the tests take a long time. This seem to me to be one of the
two general thoughts on how to do it the Erlang-way. The other one with
pattern matching but that's sometimes not an option, or at least it takes a
lot more code (I.E your example in a previous post).

One last thing; how am I refusing to discuss "a key reason why the present
(or rather, the pre-Great Blunder) state of affairs is a Good Thing." by not
wanting to use full blown application as an example? Maybe you misunderstood
me, what I wanted to know with my question was if there's a way to do this
(elseif) in Erlang in a syntactically short and easy way without getting
nested expressions. The simple answer seems to be no, and you and others
have given me examples on holve to solve it the Erlang way. I appreciate
this and I feel I gotten an answer to my question.

I ran some benchmarks on the examples I provided with lists of 30 elements
and there was no consistent efficiency winner in any of my examples but it
seemed that elseif1 (andalso & orelse) and the elseif5 (using exceptions)
was the slowest. I know micro-benchmarks is close to completely useless but
I just couldn't help myself.

BR,
Daniel Rönnqvist

2008/11/24 Richard O'Keefe <ok@REDACTED>

>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081125/bb3a0f26/attachment.htm>