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

empro2@REDACTED empro2@REDACTED
Tue Jul 24 12:26:57 CEST 2018


Am Tue, 24 Jul 2018 09:19:56 +0200
schrieb Pierre Fenoll <pierrefenoll@REDACTED>:

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





More information about the erlang-questions mailing list