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

Ivan Uemlianin ivan@REDACTED
Mon Jul 23 16:28:32 CEST 2018


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 <be.dmitry@REDACTED 
>> <mailto:be.dmitry@REDACTED>> 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 
>> <jesper.louis.andersen@REDACTED 
>> <mailto:jesper.louis.andersen@REDACTED>> wrote:
>>
>>     On Sun, Jul 22, 2018 at 9:09 PM Jachym Holecek
>>     <freza@REDACTED <mailto:freza@REDACTED>> 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
>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

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

Ymchwil a Datblygu Technoleg Lleferydd
Speech Technology Research and Development

                     ivan@REDACTED
                         @llaisdy
                          llaisdy.wordpress.com
               github.com/llaisdy
                      www.linkedin.com/in/ivanuemlianin

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180723/1caeaa08/attachment.htm>


More information about the erlang-questions mailing list