Orelse and andalso as short-hand for case

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

Orelse and andalso as short-hand for case

Viktor Söderqvist
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
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Loïc Hoguin-3
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.

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

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
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

Robert Raschke
In reply to this post by Viktor Söderqvist
I think this kind of style originated in languages like Perl, Lua and Javascript for writing shorthand code for default values. Things like "v = v or -1".

From there things spread, leading to odd combinations, like the examples you quote with side effects.

In the end it is about readability, sometimes the shortcut can read nicer than a case or if statement. And sometimes it is clearer to be a teensy bit more verbose.

Robby


On 22 Jul 2018 14:25, "Viktor Söderqvist" <[hidden email]> 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

Jachym Holecek
In reply to this post by Viktor Söderqvist
Hi,

# Viktor Söderqvist 2018-07-22:
> 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?

It is horrible style. Pain to read, pain to modify, pain to reason about.

Simple clear question deserves a simple clear answer. :-)

BR,
        -- Jachym
_______________________________________________
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

Jesper Louis Andersen-2
On Sun, Jul 22, 2018 at 9:09 PM Jachym Holecek <[hidden email]> wrote:
# Viktor Söderqvist 2018-07-22:
>
>     Msg /= undefined andalso io:format("Message: ~s~n", [Msg]),
>
> I this good or bad style?

It is horrible style. Pain to read, pain to modify, pain to reason about.

Simple clear question deserves a simple clear answer. :-)


​I don't like the style either, mostly because it messes with the types. andalso and orelse expects boolean expressions, but the style used breaks that format. However, something like

[x || Msg /= undefined]

doesn't.​


--
J.

_______________________________________________
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

Dmytro Lytovchenko
Just checked that a function is not created when you compile [X || condition] and it creates a check and a branch instruction.
Amazing.
Thanks for the tip.

2018-07-23 13:05 GMT+02:00 Jesper Louis Andersen <[hidden email]>:
On Sun, Jul 22, 2018 at 9:09 PM Jachym Holecek <[hidden email]> wrote:
# Viktor Söderqvist 2018-07-22:
>
>     Msg /= undefined andalso io:format("Message: ~s~n", [Msg]),
>
> I this good or bad style?

It is horrible style. Pain to read, pain to modify, pain to reason about.

Simple clear question deserves a simple clear answer. :-)


​I don't like the style either, mostly because it messes with the types. andalso and orelse expects boolean expressions, but the style used breaks that format. However, something like

[x || Msg /= undefined]

doesn't.​


--
J.

_______________________________________________
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

黃耀賢 (Yau-Hsien Huang)
In reply to this post by Jesper Louis Andersen-2
IMO, it's meaningful.

Think that,

Msg /= nil and io:fwrite("blah, blah, ...~n"). %% It won't build a boolean expression.

But

Msg /= nil andalso io:fwrite("blah, blah, ...~n"). %% Confirm the Msg is nothing and also say "blah, blah, ..."

I think the reason why andalso/2 was built. Though, andalso/2 won't be used for a general default value usage like what we saw in JS or Perl, because the first argument of andalso/2 must be either true or false.



On Mon, Jul 23, 2018 at 7:05 PM, Jesper Louis Andersen <[hidden email]> wrote:
On Sun, Jul 22, 2018 at 9:09 PM Jachym Holecek <[hidden email]> wrote:
# Viktor Söderqvist 2018-07-22:
>
>     Msg /= undefined andalso io:format("Message: ~s~n", [Msg]),
>
> I this good or bad style?

It is horrible style. Pain to read, pain to modify, pain to reason about.

Simple clear question deserves a simple clear answer. :-)


​I don't like the style either, mostly because it messes with the types. andalso and orelse expects boolean expressions, but the style used breaks that format. However, something like

[x || Msg /= undefined]

doesn't.​


--
J.

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




--

Best Regards.

--- Y-H. H.


_______________________________________________
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 Jesper Louis Andersen-2
How does it mess with types? The andalso and orelse operators should only care about the type of the first operand and it always is boolean.

I personally don't like list comprehension as brackets create additional noise and might not be obvious to other developers.

Also dialyzer may complain about unused value in either of ways, so the cleanest is probably case or if. The latter in Elixir doesn't require else branch which reduces noise a little bit.

On 23 July 2018 21:05:37 GMT+10:00, Jesper Louis Andersen <[hidden email]> wrote:
On Sun, Jul 22, 2018 at 9:09 PM Jachym Holecek <[hidden email]> wrote:
# Viktor Söderqvist 2018-07-22:
>
>     Msg /= undefined andalso io:format("Message: ~s~n", [Msg]),
>
> I this good or bad style?

It is horrible style. Pain to read, pain to modify, pain to reason about.

Simple clear question deserves a simple clear answer. :-)


​I don't like the style either, mostly because it messes with the types. andalso and orelse expects boolean expressions, but the style used breaks that format. However, something like

[x || Msg /= undefined]

doesn't.​


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

Jesper Louis Andersen-2
On Mon, Jul 23, 2018 at 3:32 PM Dmitry Belyaev <[hidden email]> wrote:
How does it mess with types? The andalso and orelse operators should only care about the type of the first operand and it always is boolean.


​Assume a GADT or dependently typed language. Then we have something like (forgive me the rust on the Agdaish notation used here):

data Ty where
  Bool : Ty
  Int : Ty

data Expr (t : Ty) : Set where
  andAlso : Expr Bool -> Expr Bool -> Expr Bool
  orElse : Expr Bool -> Expr Bool -> Expr Bool
  ...

​and this is the normal canonical definition most statically typed languages use. You propose

data Expr (t : Ty) : Set where
  andAlso : Expr Bool -> Expr t -> Expr ?
  orElse : Expr Bool -> Expr t -> Expr ?
  ...

but the complication is that you have to be able to tell the system what the '?' should be. It is some union type over either Bool or t for any type t, but this easily complicates the type rules of the language. This is why I say it is a "mess". You might come up with a solution, but that solution will usually lead to an acceptance of a larger body of programs in which some of the programs will be weaker from a type perspective. Or it will lead to programs which has to do more runtime checking which are slower programs.

Finally, in a dynamically typed language like Erlang, you indeed can give it a somewhat meaningful result by your proposal. But my view, as it often does, comes from 15 years of statically typed programming in Standard ML, OCaml and Haskell.



_______________________________________________
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

greim
In reply to this post by Dmitry Belyaev-3
"Programs must not regarded as code for computers,
but as literature for humans"

Nicklaus Wirth, Turing Award 1984

.......
so whats your opinion about:

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

or much more readable and clear with a well defined operator, because we
have a functional language:

Msg /= undefined F@*#! io:format("Message: ~s~n", [Msg]),

Markus Greim

Am 23.07.2018 um 15:32 schrieb Dmitry Belyaev:

> How does it mess with types? The andalso and orelse operators should
> only care about the type of the first operand and it always is boolean.
>
> I personally don't like list comprehension as brackets create additional
> noise and might not be obvious to other developers.
>
> Also dialyzer may complain about unused value in either of ways, so the
> cleanest is probably case or if. The latter in Elixir doesn't require
> else branch which reduces noise a little bit.
>
> On 23 July 2018 21:05:37 GMT+10:00, Jesper Louis Andersen
> <[hidden email]> wrote:
>
>     On Sun, Jul 22, 2018 at 9:09 PM Jachym Holecek <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         # Viktor Söderqvist 2018-07-22:
>          >
>          >     Msg /= undefined andalso io:format("Message: ~s~n", [Msg]),
>          >
>          > I this good or bad style?
>
>         It is horrible style. Pain to read, pain to modify, pain to
>         reason about.
>
>         Simple clear question deserves a simple clear answer. :-)
>
>
>     ​I don't like the style either, mostly because it messes with the
>     types. andalso and orelse expects boolean expressions, but the style
>     used breaks that format. However, something like
>
>     [x || Msg /= undefined]
>
>     doesn't.​
>
>
> --
> 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

Dmitry Kolesnikov-2
In reply to this post by Dmitry Belyaev-3
This is a clear case for Option data type…

I would prefer to use explicit definition of a function that is able to handle undefined values 

```
print(undefined) ->
   undefined;
print(Msg) ->
   io:format("Message: ~s~n", [Msg]).
``` 

Alternatively, there is a parse transforms for composition of maybe/option types (https://github.com/fogfish/datum/blob/master/doc/category.md#option)

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.

Best Regards, 
Dmitry 


On 23 Jul 2018, at 16.32, Dmitry Belyaev <[hidden email]> wrote:

How does it mess with types? The andalso and orelse operators should only care about the type of the first operand and it always is boolean.

I personally don't like list comprehension as brackets create additional noise and might not be obvious to other developers.

Also dialyzer may complain about unused value in either of ways, so the cleanest is probably case or if. The latter in Elixir doesn't require else branch which reduces noise a little bit.

On 23 July 2018 21:05:37 GMT+10:00, Jesper Louis Andersen <[hidden email]> wrote:
On Sun, Jul 22, 2018 at 9:09 PM Jachym Holecek <[hidden email]> wrote:
# Viktor Söderqvist 2018-07-22:
>
>     Msg /= undefined andalso io:format("Message: ~s~n", [Msg]),
>
> I this good or bad style?

It is horrible style. Pain to read, pain to modify, pain to reason about.

Simple clear question deserves a simple clear answer. :-)


​I don't like the style either, mostly because it messes with the types. andalso and orelse expects boolean expressions, but the style used breaks that format. However, something like

[x || Msg /= undefined]

doesn't.​


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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Ivan Uemlianin
Yes, same here.  Anything clever but unreadable I would put in an informatively-named function.  I might call this print_unless_undefined/1.

Ivan


On 23/07/2018 15:16, Dmitry Kolesnikov wrote:
This is a clear case for Option data type…

I would prefer to use explicit definition of a function that is able to handle undefined values 

```
print(undefined) ->
   undefined;
print(Msg) ->
   io:format("Message: ~s~n", [Msg]).
``` 

Alternatively, there is a parse transforms for composition of maybe/option types (https://github.com/fogfish/datum/blob/master/doc/category.md#option)

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.

Best Regards, 
Dmitry 


On 23 Jul 2018, at 16.32, Dmitry Belyaev <[hidden email]> wrote:

How does it mess with types? The andalso and orelse operators should only care about the type of the first operand and it always is boolean.

I personally don't like list comprehension as brackets create additional noise and might not be obvious to other developers.

Also dialyzer may complain about unused value in either of ways, so the cleanest is probably case or if. The latter in Elixir doesn't require else branch which reduces noise a little bit.

On 23 July 2018 21:05:37 GMT+10:00, Jesper Louis Andersen <[hidden email]> wrote:
On Sun, Jul 22, 2018 at 9:09 PM Jachym Holecek <[hidden email]> wrote:
# Viktor Söderqvist 2018-07-22:
>
>     Msg /= undefined andalso io:format("Message: ~s~n", [Msg]),
>
> I this good or bad style?

It is horrible style. Pain to read, pain to modify, pain to reason about.

Simple clear question deserves a simple clear answer. :-)


​I don't like the style either, mostly because it messes with the types. andalso and orelse expects boolean expressions, but the style used breaks that format. However, something like

[x || Msg /= undefined]

doesn't.​


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

-- 
============================================================
Ivan A. Uemlianin PhD
Llaisdy

Ymchwil a Datblygu Technoleg Lleferydd
Speech Technology Research and Development

                    [hidden email]
                        @llaisdy
                         llaisdy.wordpress.com
              github.com/llaisdy
                     www.linkedin.com/in/ivanuemlianin

                        festina lente
============================================================ 

_______________________________________________
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

Danil Zagoskin-2
In reply to this post by Viktor Söderqvist
Hi!

I find this style convenient for debugging.
Sometimes you need some binding to be logged, but only under some rare conditions. After the problem is fixed the added code should be removed or commented-out.

Adding a simple if (or case) costs you 4 lines and an extra tabulation.
Removing/disabling that requires selecting several lines, then deleting/commenting them.

Adding a wrapper function invades the code in two places.
Removing that requires extra seeking to the helper function. Disabling (commenting the call) requires disabling the function too,
to avoid unused function warning. Much pain.

A single-liner with andalso/orelse is easy to write (shorter than other options) and easy to remove/disable (just jump to line + single dd or I in vim).

On Sun, Jul 22, 2018 at 3:25 PM Viktor Söderqvist <[hidden email]> 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


--
Danil Zagoskin | [hidden email]

_______________________________________________
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

黃耀賢 (Yau-Hsien Huang)
In reply to this post by 黃耀賢 (Yau-Hsien Huang)
Though the RHS of andalso is not typed in Erlang.

On Mon, Jul 23, 2018 at 10:35 PM, Richard O'Keefe <[hidden email]> wrote:
No, that is *not* why andalso/2 was added to the language.
The very spelling of the token, 'andalso', was copied from
a language, Standard ML, which is strictly typed and does
not allow <test> andalso <action>.

On 23 July 2018 at 23:25, 黃耀賢 (Yau-Hsien Huang) <[hidden email]> wrote:
IMO, it's meaningful.

Think that,

Msg /= nil and io:fwrite("blah, blah, ...~n"). %% It won't build a boolean expression.

But

Msg /= nil andalso io:fwrite("blah, blah, ...~n"). %% Confirm the Msg is nothing and also say "blah, blah, ..."

I think the reason why andalso/2 was built. Though, andalso/2 won't be used for a general default value usage like what we saw in JS or Perl, because the first argument of andalso/2 must be either true or false.



On Mon, Jul 23, 2018 at 7:05 PM, Jesper Louis Andersen <[hidden email]> wrote:
On Sun, Jul 22, 2018 at 9:09 PM Jachym Holecek <[hidden email]> wrote:
# Viktor Söderqvist 2018-07-22:
>
>     Msg /= undefined andalso io:format("Message: ~s~n", [Msg]),
>
> I this good or bad style?

It is horrible style. Pain to read, pain to modify, pain to reason about.

Simple clear question deserves a simple clear answer. :-)


​I don't like the style either, mostly because it messes with the types. andalso and orelse expects boolean expressions, but the style used breaks that format. However, something like

[x || Msg /= undefined]

doesn't.​


--
J.

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




--

Best Regards.

--- Y-H. H.


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





--

Best Regards.

--- Y-H. H.


_______________________________________________
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

黃耀賢 (Yau-Hsien Huang)
I'm not interested in so-called "it's for something but the other." By typing some code in both shell, I got an error message in SML/NJ when typing the following code,

> true andalso nil;

though I got similar code working smoothly in Erlang when typing the following code,

> is_list(true andalso []). %% The shell reported `true`.

So, what's the meaning of "being copied into?" Is it rigid that you borrow a word from a language and keep all the nature of it? I don't think so.



On Tue, Jul 24, 2018 at 12:58 AM, Richard O'Keefe <[hidden email]> wrote:
Yes, I know the RHS of 'andalso' is not typed in Erlang.
So what?  The point is that when 'andalso' and 'orelse'
were copied into Erlang from Standard ML, they did not
drag the obsolete baggage of being ersatzes for WHEN and
UNLESS in with them.  They were added to provide
non-strict AND and OR for Boolean expressions, and that
is all they were added for, just as 'and' and 'or' were
added to provide strict AND and OR.

They were not added to provide a cryptic way to obfuscate
conditionals you could already easily write.



On 24 July 2018 at 03:48, 黃耀賢 (Yau-Hsien Huang) <[hidden email]> wrote:
Though the RHS of andalso is not typed in Erlang.

On Mon, Jul 23, 2018 at 10:35 PM, Richard O'Keefe <[hidden email]> wrote:
No, that is *not* why andalso/2 was added to the language.
The very spelling of the token, 'andalso', was copied from
a language, Standard ML, which is strictly typed and does
not allow <test> andalso <action>.

On 23 July 2018 at 23:25, 黃耀賢 (Yau-Hsien Huang) <[hidden email]> wrote:
IMO, it's meaningful.

Think that,

Msg /= nil and io:fwrite("blah, blah, ...~n"). %% It won't build a boolean expression.

But

Msg /= nil andalso io:fwrite("blah, blah, ...~n"). %% Confirm the Msg is nothing and also say "blah, blah, ..."

I think the reason why andalso/2 was built. Though, andalso/2 won't be used for a general default value usage like what we saw in JS or Perl, because the first argument of andalso/2 must be either true or false.



On Mon, Jul 23, 2018 at 7:05 PM, Jesper Louis Andersen <[hidden email]> wrote:
On Sun, Jul 22, 2018 at 9:09 PM Jachym Holecek <[hidden email]> wrote:
# Viktor Söderqvist 2018-07-22:
>
>     Msg /= undefined andalso io:format("Message: ~s~n", [Msg]),
>
> I this good or bad style?

It is horrible style. Pain to read, pain to modify, pain to reason about.

Simple clear question deserves a simple clear answer. :-)


​I don't like the style either, mostly because it messes with the types. andalso and orelse expects boolean expressions, but the style used breaks that format. However, something like

[x || Msg /= undefined]

doesn't.​


--
J.

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




--

Best Regards.

--- Y-H. H.


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





--

Best Regards.

--- Y-H. H.


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





--

Best Regards.

--- Y-H. H.


_______________________________________________
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 Viktor Söderqvist
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
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

Pierre Fenoll-2
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: 

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
Reply | Threaded
Open this post in threaded view
|

Re: Orelse and andalso as short-hand for case

greim
In reply to this post by Ivan Uemlianin
Am 23.07.2018 um 16:28 schrieb Ivan Uemlianin:
> Yes, same here.  Anything clever but unreadable I would put in an
> informatively-named function.  I might call this print_unless_undefined/1.
>

yep, now we are going in the right direction, that is self explaining!

Markus


> Ivan
>
>
> On 23/07/2018 15:16, Dmitry Kolesnikov wrote:
>> This is a clear case for Option data type…
>>
>> I would prefer to use explicit definition of a function that is able
>> to handle undefined values
>>
>> ```
>> print(undefined) ->
>>    undefined;
>> print(Msg) ->
>>    io:format("Message: ~s~n", [Msg]).
>> ```
>>
>> Alternatively, there is a parse transforms for composition of
>> maybe/option types
>> (https://github.com/fogfish/datum/blob/master/doc/category.md#option)
>>
>> 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.
>>
>> Best Regards,
>> Dmitry
>>
>>
>>> On 23 Jul 2018, at 16.32, Dmitry Belyaev <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>> How does it mess with types? The andalso and orelse operators should
>>> only care about the type of the first operand and it always is boolean.
>>>
>>> I personally don't like list comprehension as brackets create
>>> additional noise and might not be obvious to other developers.
>>>
>>> Also dialyzer may complain about unused value in either of ways, so
>>> the cleanest is probably case or if. The latter in Elixir doesn't
>>> require else branch which reduces noise a little bit.
>>>
>>> On 23 July 2018 21:05:37 GMT+10:00, Jesper Louis Andersen
>>> <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>     On Sun, Jul 22, 2018 at 9:09 PM Jachym Holecek
>>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>         # Viktor Söderqvist 2018-07-22:
>>>         >
>>>         >     Msg /= undefined andalso io:format("Message: ~s~n", [Msg]),
>>>         >
>>>         > I this good or bad style?
>>>
>>>         It is horrible style. Pain to read, pain to modify, pain to
>>>         reason about.
>>>
>>>         Simple clear question deserves a simple clear answer. :-)
>>>
>>>
>>>     ​I don't like the style either, mostly because it messes with the
>>>     types. andalso and orelse expects boolean expressions, but the
>>>     style used breaks that format. However, something like
>>>
>>>     [x || Msg /= undefined]
>>>
>>>     doesn't.​
>>>
>>>
>>> --
>>> Kind regards,
>>> Dmitry Belyaev
>>> _______________________________________________
>>> erlang-questions mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> --
> ============================================================
> Ivan A. Uemlianin PhD
> Llaisdy
>
> Ymchwil a Datblygu Technoleg Lleferydd
> Speech Technology Research and Development
>
>                      [hidden email]
>                          @llaisdy
>                           llaisdy.wordpress.com
>                github.com/llaisdy
>                       www.linkedin.com/in/ivanuemlianin
>
>                          festina lente
> ============================================================
>
>
>
> _______________________________________________
> 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
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 Pierre Fenoll-2
2018-07-24 10:19 GMT+03:00 Pierre Fenoll <[hidden email]>:
I don’t understand the strong answers.


Do not pay attention to ruby-influensed people :)

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

zxq9-2
In reply to this post by Pierre Fenoll-2
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.

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