Orelse and andalso as short-hand for case

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

empro2
Am Tue, 24 Jul 2018 09:19:56 +0200
schrieb Pierre Fenoll <[hidden email]>:

> I don’t understand the strong answers.

Then let me try to help :-)


> To me the semantics of orelse/and also are well known.

Are they? Or do you merely know of a different way to
(ab)use them?


> They are even known as ||/&& in the mainstream.

The "mainstream"? or C and bash and whatever? What about
Perl's: succeed() or die("fast")?


> They have their use as the common boolean shortcut
> operators.

Languages have their (ab)use by marketing persons and
spokespeople and lawyers; but does that make a better -
easier to learn, expressive, concise - language? a better
world for everyone (or most, actually)?


> These operators are very interesting semantics.

See? Now I have to guess whether this is merely a
(completely acceptable) mistake or something I do not (yet)
understand. Operators are no semantics, but ... It may as
well be that you confuse semantics with syntax, because you
say "easy-to-comment" below, so it might be the syntax
that appeals to you (and others, this all is not
meant to be personal :-).


> not exactly a pure language.

Off topic, this is about whether one codes for the compiler
or the programmer. No compiler has ever lamented about the
Obfuscated C Code Contest, full of things one _can_
write ... "Pure"? like 'completely and only functional'?
All programs will eventually push something to an output
device, which is inherently non-functional (or is it?)


> Being able to express side
> effects in such an easy-to-comment amount of code that’s
> just priceless.

Concise is fine, simply and only and first of all 'few
lines' is not price- but ruthless.


> Here’s a legit example:
> https://github.com/2600hz/kazoo/blob/master/applications/tasks/src/kz_tasks_scheduler.erl#L526

Is it legit? why? Why not:

  if Pid =:= WorkerPid -> throw({'task', Task}) end,

? Not even now I am sure that this translation is correct,
and that after the much too long time that code forced me
to spend on understanding it. I am sure the compiler does
not complain ...


> So why the big words? What’s next, the process
> dictionary, using list comprehensions with 1-element
> lists generators?

In what better way would you express the process dict? Or
why not spawn a function and stuff all state into its
dictionary, have set/2 and get/1 to mutate and read the
attributes and call it OOerlang ... or WoeWoeErlang ...

If you want to translate/map or reduce/filter a list A to
produce a list B, it does not matter whether A happens to
have only one element or none (apart from []) or several or
many; that is what lists and list comprehension are meant
for. If one does not want to process a list, and does not
even want but create one -

        [x || Msg /= undefined]

- then ... perhaps the author should die in a fire ;-)

Note: it does not matter what the compiler (writer) makes
of this.


> 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?

So if people have trouble walking on their hands they need
more practice?

Michael

P. S. All "you"s and "I"s are to be read as 'one'. This
really is not meant to be personal.

--

That, which was said, is not that, which was spoken,
but that, which was understood; and none of these
comes necessarily close to that, which was meant.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Nathaniel Waisbrot
In reply to this post by zxq9-2

> On Jul 24, 2018, at 4:00 AM, [hidden email] wrote:
>
>> On 2018年7月24日火曜日 9時19分56秒 JST Pierre Fenoll wrote:
>> I don’t understand the strong answers.
>> To me the semantics of orelse/and also are well known.
>
> "To me... well known"
>
> Says it all.


Well, it’s a pattern I’ve seen in both lisp and javascript, so I agree that it’s not a totally wild idea. A pretty wide swath of programmers should be able to recognize what’s happening.  

I feel like avoiding the pattern is more on the language than the programmer, too. You don’t see this pattern in languages without side-effects and you don’t get it when both sides of && must be booleans. OTOH if the language hands me a tool and I see a convenient use for it, why should I hold back?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Dmitry Belyaev-3
In reply to this post by empro2


On 24 July 2018 20:26:57 GMT+10:00, [hidden email] wrote:
>...
>Why not:
>
>  if Pid =:= WorkerPid -> throw({'task', Task}) end,
>

Because it doesn't work for the false case. In Erlang if and case are expressions and they have to be exhaustive and return values for each case. Otherwise they will throw errors.
--
Kind regards,
Dmitry Belyaev
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Led
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Led
In reply to this post by empro2
2018-07-24 13:26 GMT+03:00 <[hidden email]>:
Why not:

  if Pid =:= WorkerPid -> throw({'task', Task}) end,

?


Are you serious?
Or is this a joke?

--
Led.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Raimo Niskanen-2
In reply to this post by Loïc Hoguin-3
On Sun, Jul 22, 2018 at 02:32:29PM +0200, Loïc Hoguin wrote:

> Neither.
>
> The problem with this and the list comprehension equivalent
>
>      [io:format("Message: ~s~n", [Msg]) || Msg /= undefined]
>
> is that it will confuse people who never encountered it before.
>
> But if one or both of these forms were teached to beginners and everyone
> was using them, then there'd be no problem in using them anymore.
>
> I'd love if they became more popular.

I do not mind writing nor reading

     Msg /= undefined andalso
         io:format("Message: ~s~n", [Msg]),

but find

    [io:format("Message: ~s~n", [Msg]) ||
         Msg /= undefined]

a bit harder to read because the condition comes after the action.

I prefer in any case to use two lines with indentation to hint about
the flow control usage.

(Doesn't Dialyzer complain about the 'andalso' variant because it may
 return a 'false' that is ignored?)

Erlang does not have many "ugly tricks" like these, so if it can save
me from 4 uninteresting code lines i certainly do not mind:

    case Msg of
        undefined ->
            ok;
        _ ->
            io:format("Message: ~s~n", [Msg])
    end


>
> Cheers,
>
> On 07/22/2018 02:25 PM, 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?
> >
>
> --
> Loïc Hoguin
> https://ninenines.eu

--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

empro2
In reply to this post by Led
Am Tue, 24 Jul 2018 17:30:46 +0300
schrieb Led <[hidden email]>:

> 2018-07-24 13:26 GMT+03:00 <[hidden email]>:
>
> > Why not:
> >
> >   if Pid =:= WorkerPid -> throw({'task', Task}) end,
> >
> > ?


> Are you serious?
> Or is this a joke?

Sorry! do not attribute to jest what can be explained with
simple stupidity - or so the saying goes ... :-)

Perhaps it was the mentioning of WHEN and UNLESS (that
remove the need for PROGN and the "else" in LISP), perhaps
it was seeing the use of a list comprehension without a list
producing one that was not wanted, perhaps I was
simply trying not to like the "andalso" (which is only
possible since R13A
http://erlang.org/doc/reference_manual/expressions.html#short-circuit-expressions)
or perhaps there is a reason for my "if" being nonsense and
that reason is not to be circumvented with "andalso" ...

... but I seem to be too stupid to see that (yet) :-)

Michael

--

If a bank in need of money is systematically important,
then that system is not important.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Viktor Söderqvist
In reply to this post by Viktor Söderqvist
Thank you all for the diverse opinions!

Especially, I liked this point from Dmitry Kolesnikov:

> Long time ago, I’ve used andalso syntax but it never stays longer at
> code repository due to readability. It has been refactored to
> function(s) with guards or pattern match.

I think it is the process from prototyping to maintained code.
Refactoring involves gradually adding names to things by introducing
functions, adding specs and rewriting hacks into proper solutions. A
spec with a return type like false | ok | {error, Reason} would make me
reconsider the andalso trick. I guess this process gradually makes the
code change style from dynamically typed style (LISP, Perl) to
statically typed style (ML, Haskell). I find this interesting.

Viktor


On 2018-07-22 14:25, 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?
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

zxq9-2
In reply to this post by Pierre Fenoll-2
For whatever reason, Richard's responses never made it into the archive.
I believe they are worthy of preservation.

-Craig

On 2018年7月25日水曜日 15時00分03秒 JST Richard O'Keefe wrote:

> Pierre Fenoli does not "understand the strong answers".
> I imagine that other people have had the experience of having to maintain
> someone else's code, and after a long struggle to disentangle unduly
> "clever"
> code found themselves shouting "Why did this offspring of an incestuous
> union between two male naked mole-rats not remove xer hands from xer
> genitals long enough to write down what xie actually meant and NOT WASTE
> MY RAPIDLY DWINDLING TIME?"
>
> I am still nowhere near as good a programmer as I would like to be.
> I need to make my own code clearer.
> "What is hateful to you, do not do to others."
> If anyone catches me abusing short-circuit operations, my apologies
> in advance.
>
> The andalso and orelse operators are defined in section 8.14
> http://erlang.org/doc/reference_manual/expressions.html#short-circuit-expressions
> of the Erlang reference manual.  It is clear from that that
> these operators originally required their right operand to yield
> true or false, and were only changed in order to allow code like
>
>
> ismember(X, [Y|Ys]) -> X == Y orelse ismember(X, Ys);
> ismember(_, []    ) -> false.
>
> to be tail recursive.
>
> It would be really nice if the Dialyzer would warn about misuses of
> these operators.  What about the 'legit example' we were offered?
> It is a blemish in an otherwise pleasant file in an impressive and
> useful project.  The only occurrence of 'andalso' in that 628 line
> file is a good example of when NOT to use 'andalso'.
>
> task_by_pid(Pid, #state{tasks = Tasks}) ->
>     F = fun (_, #{worker_pid := WorkerPid}=Task, Acc) ->
>                 Pid =:= WorkerPid
>                     andalso throw({'task', Task}),
>                 Acc
>         end,
>     try maps:fold(F, 'undefined', Tasks)
>     catch 'throw':{'task', Task} -> Task
>     end.
>
> which is 9 lines.  It garden-paths the reader into a
> sort of double negation.  The goal of F is *not* to return Acc,
> but to find a Task, and the throw is *not* there to report
> failure, but success.
>
> This can be written, not only without 'andalso',
> but also without 'throw' and 'catch', as
>
> task_by_id(Pid, #state{tasks = Tasks}) ->
>     task_with_matching_worker_pid(Pid, Tasks).
>
> task_with_matching_worker_pid(Pid, [Task = #{worker_pid := Pid}|_]) ->
>     Task;
> task_with_matching_worker_pid(Pid, [_|Tasks]) ->
>     task_with_matching_worker_pid(Pid, Tasks);
> task_with_matching_worker_pid(_, []) ->
>     undefined.
>
> which is also 9 lines.  To me this is a fairly obvious linear
> search for a matching list element, which leaves me free to
> think about things like whether a map from worker Pids to Tasks
> might not be a better data structure, and also lets me muse,
> "hmm, isn't there already a library function to look for the
> first matching list element?  Oh yeah."
>
> task_by_pid(Pid, #state{tasks = Tasks}) ->
>     case lists:search(fun (#{worker_pid := Id}) -> Id =:= Pid end, Tasks)
>       of {value, Task} -> Task
>        ; false         -> undefined
>     end.
>
> which is now 5 lines, and is how I'd have written it in the first place.
>
> I honestly wasn't expecting this.  Given that this was Kazoo, I
> was expecting to have to mumble and shuffle and say "well, maybe
> OCCASIONALLY you can get away with it in otherwise really good
> code", but the abuse of 'andalso' DID turn out to be a 'code smell'
> pointing to contorted code that needed rewriting.
>
> If, as would not be surprising, I have misunderstood thpe original
> code, that just proves my point that it was contorted.
>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

zxq9-2
In reply to this post by Nathaniel Waisbrot
On 2018年7月25日水曜日 15時09分28秒 JST Richard O'Keefe wrote:

> On 25 July 2018 at 00:06, Nathaniel Waisbrot <[hidden email]> wrote:
>
> >  if the language hands me a tool and I see a convenient use for it, why
> > should I hold back?
> >
>
> Out of consideration for anyone reading the code in the future,
> including yourself.  The language hands you many tools; if you
> need a chisel and you *have* a chisel, why use a screwdriver?
>
> Or as Dr Johnson put it, "Read over your compositions, and
> wherever you meet with a passage which you think is particularly
> fine, strike it out."

This painful guideline saves me much torment every time I find the fortitude to apply it.

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Per Hedeland
In reply to this post by zxq9-2
On 2018-07-27 01:52, [hidden email] wrote:
> For whatever reason, Richard's responses never made it into the archive.

Actually, it seems his messages consistently do not even reach the
*list*, and are seen only when quoted in other messages - is there some
broken filter on the list, or is he intentionally doing
reply-to-sender-only? (Or did he just switch to a mail client that needs
"Reply-To: <list>"? And no, let's not start that discussion again...)

> I believe they are worthy of preservation.

+1!:-)

--Per
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

zxq9-2
On 2018年7月27日金曜日 8時37分44秒 JST Per Hedeland wrote:

> On 2018-07-27 01:52, [hidden email] wrote:
> > For whatever reason, Richard's responses never made it into the archive.
>
> Actually, it seems his messages consistently do not even reach the
> *list*, and are seen only when quoted in other messages - is there some
> broken filter on the list, or is he intentionally doing
> reply-to-sender-only? (Or did he just switch to a mail client that needs
> "Reply-To: <list>"? And no, let's not start that discussion again...)
>
> > I believe they are worthy of preservation.
>
> +1!:-)

I'm not sure. A lot of the messages from him I wind up getting I receive
because I'm on the recipient list separately from the ML (maybe from "reply
to all"?). erlang-questions is usually just CC'd -- which should work just
fine. I can't imagine anyone would filter ROK's messages *out* of the list.
Much to the contrary, if I had the time I would put together a compilation
of his best posts/threads!

So, Richard, if you happen to read this... any idea why your mail isn't
hitting the list lately? Maybe one account or another is unsubscribed?

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Fred Hebert-2
On 07/28, [hidden email] wrote:
>
>So, Richard, if you happen to read this... any idea why your mail isn't
>hitting the list lately? Maybe one account or another is unsubscribed?
>

A common cause of problems for Mailing lists is the presence or absence
of an SPF record for custom domains. I can't see ROK's e-mail address
from your reposts, but you can do a quick check by doing a DNS lookup.  
Here's mine for example:

→ dig ferd.ca ANY
...
;; ANSWER SECTION:
ferd.ca.                3599    IN      A       208.94.116.79
ferd.ca.                3599    IN      MX      5 ALT2.ASPMX.L.GOOGLE.COM.
ferd.ca.                3599    IN      MX      10 ASPMX5.GOOGLEMAIL.COM.
...
ferd.ca.                3599    IN      TXT     "v=spf1 include:_spf.google.com ~all"
ferd.ca.                3599    IN      SOA     ns.phx1.nearlyfreespeech.net. hostmaster.nearlyfreespeech.net. 1406273317 600 180 86400 180

The MX records indicate that I'm redirecting everything on gmail, but
the critical one not to be seen as spam or a spoofed e-mail is the TXT
record with the SPF entry in it.

Background info is at https://support.dnsimple.com/articles/spf-record/ 
or https://en.wikipedia.org/wiki/Sender_Policy_Framework
-- your mail provider should possibly be able to give a line about it so
people can configure their stuff themselves. Google's page is at
https://support.google.com/a/answer/33786?hl=en if you're using gmail.

There's a good chance that something like that could be to blame for
missing/non-forwarded e-mails.

Regards,
Fred.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Dmitry Belyaev-3
I believe Richard's email was provided in one of the responses:

On Mon, Jul 23, 2018 at 10:35 PM, Richard O'Keefe <[hidden email]> wrote:
...

To me it looks like either mailing list configuration or usage of reply instead of reply all - I often do forget about that in Gmail web UI and even in my mobile email client.


On 28 July 2018 12:29:57 GMT+10:00, Fred Hebert <[hidden email]> wrote:
On 07/28, [hidden email] wrote:

So, Richard, if you happen to read this... any idea why your mail isn't
hitting the list lately? Maybe one account or another is unsubscribed?


A common cause of problems for Mailing lists is the presence or absence
of an SPF record for custom domains. I can't see ROK's e-mail address
from your reposts, but you can do a quick check by doing a DNS lookup.
Here's mine for example:

→ dig ferd.ca ANY
...
;; ANSWER SECTION:
ferd.ca. 3599 IN A 208.94.116.79
ferd.ca. 3599 IN MX 5 ALT2.ASPMX.L.GOOGLE.COM.
ferd.ca. 3599 IN MX 10 ASPMX5.GOOGLEMAIL.COM.
...
ferd.ca. 3599 IN TXT "v=spf1 include:_spf.google.com ~all"
ferd.ca. 3599 IN SOA ns.phx1.nearlyfreespeech.net. hostmaster.nearlyfreespeech.net. 1406273317 600 180 86400 180

The MX records indicate that I'm redirecting everything on gmail, but
the critical one not to be seen as spam or a spoofed e-mail is the TXT
record with the SPF entry in it.

Background info is at https://support.dnsimple.com/articles/spf-record/
or https://en.wikipedia.org/wiki/Sender_Policy_Framework
-- your mail provider should possibly be able to give a line about it so
people can configure their stuff themselves. Google's page is at
https://support.google.com/a/answer/33786?hl=en if you're using gmail.

There's a good chance that something like that could be to blame for
missing/non-forwarded e-mails.

Regards,
Fred.


erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

--
Kind regards,
Dmitry Belyaev
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Per Hedeland
On 2018-07-28 04:54, Dmitry Belyaev wrote:
> I believe Richard's email was provided in one of the responses:
>
> On Mon, Jul 23, 2018 at 10:35 PM, Richard O'Keefe <[hidden email]> wrote:
> ...
>
> To me it looks like either mailing list configuration or usage of reply instead of reply all - I often do forget about that in Gmail web UI and even in my mobile email client.

Surely you're not suggesting that ROK would ever *forget* anything?:-)
But mailing list configuration is likely - AFAIR, this list like most
others block messages from non-subscribers to cut down on spam. And the
last message directly from Richard that I still have in my inbox happens
to be this one:
http://erlang.org/pipermail/erlang-questions/2017-November/094170.html

Raimo did dutifully reply to that message, but one possibility is that
Richard didn't get around to re-subscribing, and get the list messages
forwarded from his old address, while his own messages that use the new
address are blocked. Raimo, maybe you can have a look? I know that it's
outside what can be expected from standard mailing list maintenance, but
this concerns a very special subscriber...

--Per

> On 28 July 2018 12:29:57 GMT+10:00, Fred Hebert <[hidden email]> wrote:
>
>     On 07/28, [hidden email] wrote:
>
>
>         So, Richard, if you happen to read this... any idea why your mail isn't
>         hitting the list lately? Maybe one account or another is unsubscribed?
>
>
>
>     A common cause of problems for Mailing lists is the presence or absence
>     of an SPF record for custom domains. I can't see ROK's e-mail address
>     from your reposts, but you can do a quick check by doing a DNS lookup.
>     Here's mine for example:
>
>     ’ dig ferd.ca ANY
>     ...
>     ;; ANSWER SECTION:
>     ferd.ca.                3599    IN      A       208.94.116.79
>     ferd.ca.                3599    IN      MX      5 ALT2.ASPMX.L.GOOGLE.COM.
>     ferd.ca.                3599    IN      MX      10 ASPMX5.GOOGLEMAIL.COM.
>     ...
>     ferd.ca.                3599    IN      TXT     "v=spf1 include:_spf.google.com ~all"
>     ferd.ca.                3599    IN      SOA     ns.phx1.nearlyfreespeech.net. hostmaster.nearlyfreespeech.net. 1406273317 600 180 86400 180
>
>     The MX records indicate that I'm redirecting everything on gmail, but
>     the critical one not to be seen as spam or a spoofed e-mail is the TXT
>     record with the SPF entry in it.
>
>     Background info is athttps://support.dnsimple.com/articles/spf-record/  
>     orhttps://en.wikipedia.org/wiki/Sender_Policy_Framework
>     -- your mail provider should possibly be able to give a line about it so
>     people can configure their stuff themselves. Google's page is at
>     https://support.google.com/a/answer/33786?hl=en  if you're using gmail.
>
>     There's a good chance that something like that could be to blame for
>     missing/non-forwarded e-mails.
>
>     Regards,
>     Fred.
>     --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>     erlang-questions mailing list
>     [hidden email]
>     http://erlang.org/mailman/listinfo/erlang-questions
>
>
> --
> Kind regards,
> Dmitry Belyaev
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Joe Harrison
In reply to this post by Pierre Fenoll-2
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'] )
            ( <_@c0> when 'true' ->
                  ( call ( 'erlang'
                           -| ['compiler_generated'] ):( 'error'
                                                         -| ['compiler_generated'] )
                        (( {( 'badarg'
                              -| ['compiler_generated'] ),_@c0}
                           -| ['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" <[hidden email]>:

> 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, <[hidden email]> 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
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
> --
>
> Cheers,
> --
> Pierre Fenoll
>
> ,
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
12