[erlang-questions] Fwd: conditional expressions

Hynek Vychodil vychodil.hynek@REDACTED
Sun Nov 16 14:19:27 CET 2008


2008/11/15 damien morton <dmorton@REDACTED>

>
>
> ---------- Forwarded message ----------
> From: damien morton <dmorton@REDACTED>
> Date: Sun, Nov 16, 2008 at 1:21 AM
> Subject: Re: [erlang-questions] conditional expressions
> To: Richard Carlsson <richardc@REDACTED>
>
>
>
>
> On Sat, Nov 15, 2008 at 10:49 PM, Richard Carlsson <richardc@REDACTED>wrote:
>
>> damien morton wrote:
>>
>>> ...
>>
>>
>>  I cant for the life of me figure out what the most concise way of stating
>>> that is in erlang.
>>>
>>> perhaps
>>>  X = if (T1=foo()) =/= [] -> T1, false -> bar() end
>>>
>>> it would nice to be able to say something like
>>>  X = foo() otherwise bar().
>>>
>>
>> X = case foo() of
>>      [] -> bar();
>>      X1 -> X1
>>    end
>>
>> If you need to check for other values as well, replace '[] ->' with
>> 'X when X =:= [] ; X =:= 0 ; ... ->'
>>
>
> Ok, that works and is reasonably concise.
>
>
>>
>>
>> But I've always felt that this feature of Python/Perl/... boils down
>> to sloppy programming style. It basically means that the caller hopes
>> that the "empty or failure" case is signalled by one of the values
>> reconized as pseudo-booleans by the language (the programmer might
>> not actually know the exact interface of the called function, but
>> guessed that this would work), and the resulting code says nothing to
>> the reader about the actual set of return values. Furthermore, the
>> code might do the wrong thing if the function tries to return e.g. '0'
>> or '{}' on success (as opposed to False or None or whatever it usually
>> uses for failure). It simply makes the code a lot less tight than it
>> ought to be. And then, you still can't use the same idiom on abstract
>> data types to treat e.g. an empty set as "false".
>
>
> Well, Python does have a way of determining if an abstract data type is
> considered true or false - there's a method the ADT can implement for that.
>
> Still, what strikes me about the erlang libraries is the tremendous variety
> of techniques used to signal the return of a value or not.
>
> Sometimes nil/Value, sometimes false/Value, sometimes []/[Value], sometimes
> false/{value,Value}
>
> For a function that can return 0 or 1 answers, I personally like the
> []/[Value] approach.
>

It happen because there is not pattern matching in python, perl, ruby, ...
but you don't need it in erlang since there is pattern matching in erlang.

>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



-- 
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081116/6134f97e/attachment.htm>


More information about the erlang-questions mailing list