[erlang-questions] Orelse and andalso as short-hand for case

[Joe Harrison]

Let's not forget what happens in the Core Erlang compilation pass:

In Erlang:

f() ->
    other:check_db_ok() andalso other:do_db_transaction().

After compilation with +to_core:

f'/0 =
    fun () ->
        ( case call 'other':'check_db_ok'
                   () of
            ( <( 'true'
                 -| ['compiler_generated'] )> when 'true' ->
                  call 'other':'do_db_transaction'
                      ()
              -| ['compiler_generated'] )
            ( <( 'false'
                 -| ['compiler_generated'] )> when 'true' ->
                  'false'
              -| ['compiler_generated'] )
            ( <_@REDACTED> when 'true' ->
                  ( call ( 'erlang'
                           -| ['compiler_generated'] ):( 'error'
                                                         -| ['compiler_generated'] )
                        (( {( 'badarg'
                              -| ['compiler_generated'] ),_@REDACTED}
                           -| ['compiler_generated'] ))
                    -| ['compiler_generated'] )
              -| ['compiler_generated'] )
          end
          -| ['compiler_generated'] )

Which, as we've all been discussing, is the same as a case expression, and furthermore is de-sugared as such.


24.07.2018, 08:20, "Pierre Fenoll" <pierrefenoll@REDACTED>:
> I don’t understand the strong answers.
> To me the semantics of orelse/and also are well known. They are even known as ||/&& in the mainstream.
> They have their use as the common boolean shortcut operators. They are even more than that:
> case ShouldOpen andalso file:open(...) of
> false ->
> {error,_} ->
> {ok,_} ->
> end
>
> These operators are very interesting semantics. Erlang is not exactly a pure language. Being able to express side effects in such an easy-to-comment amount of code that’s just priceless. Here’s a legit example:
> https://github.com/2600hz/kazoo/blob/master/applications/tasks/src/kz_tasks_scheduler.erl#L526
>
> So why the big words? What’s next, the process dictionary, using list comprehensions with 1-element lists generators?
> To me if you don’t like this kind of code it’s only because you have not needed / seen it much. So, read more code?
>
> On Tue 24 Jul 2018 at 05:42, <zxq9@REDACTED> wrote:
>> On 2018年7月22日日曜日 14時25分00秒 JST Viktor Söderqvist wrote:
>>> Hey everyone,
>>>
>>> I've seen these short-circuit operators with a non-boolean second
>>> operand, usually where the second operand is doing some side-effect and
>>> the return value is not important. It seems to be a trend. Example:
>>>
>>>     Msg /= undefined andalso io:format("Message: ~s~n", [Msg]),
>>>
>>> I this good or bad style?
>>
>> That code should die in a fire and the author should say repent with
>> the chanting of 100 Hail McCarthys.
>>
>> -Craig
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> --
>
> Cheers,
> --
> Pierre Fenoll
>
> ,
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions