<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">damien morton</b> <span dir="ltr"><<a href="mailto:dmorton@bitfurnace.com">dmorton@bitfurnace.com</a>></span><br>
Date: Sun, Nov 16, 2008 at 1:21 AM<br>Subject: Re: [erlang-questions] conditional expressions<br>To: Richard Carlsson <<a href="mailto:richardc@it.uu.se">richardc@it.uu.se</a>><br><br><br><br><br><div class="gmail_quote">
On Sat, Nov 15, 2008 at 10:49 PM, Richard Carlsson <span dir="ltr"><<a href="mailto:richardc@it.uu.se" target="_blank">richardc@it.uu.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>damien morton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...</blockquote></div><div class="Ih2E3d"><div>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I cant for the life of me figure out what the most concise way of stating that is in erlang.<br>
<br>
perhaps<br>
 X = if (T1=foo()) =/= [] -> T1, false -> bar() end<br>
<br>
it would nice to be able to say something like<br>
 X = foo() otherwise bar().<br>
</blockquote>
<br></div>
X = case foo() of<br>
      [] -> bar();<br>
      X1 -> X1<br>
    end<br>
<br>
If you need to check for other values as well, replace '[] ->' with<br>
'X when X =:= [] ; X =:= 0 ; ... ->'</div></blockquote><div><br></div><div>Ok, that works and is reasonably concise.</div><div class="Ih2E3d"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<br>
But I've always felt that this feature of Python/Perl/... boils down<br>
to sloppy programming style. It basically means that the caller hopes<br>
that the "empty or failure" case is signalled by one of the values<br>
reconized as pseudo-booleans by the language (the programmer might<br>
not actually know the exact interface of the called function, but<br>
guessed that this would work), and the resulting code says nothing to<br>
the reader about the actual set of return values. Furthermore, the<br>
code might do the wrong thing if the function tries to return e.g. '0'<br>
or '{}' on success (as opposed to False or None or whatever it usually<br>
uses for failure). It simply makes the code a lot less tight than it<br>
ought to be. And then, you still can't use the same idiom on abstract<br>
data types to treat e.g. an empty set as "false".</blockquote><div><br></div></div><div>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. </div>

<div><br></div><div>Still, what strikes me about the erlang libraries is the tremendous variety of techniques used to signal the return of a value or not.<br></div><div><br></div><div>Sometimes nil/Value, sometimes false/Value, sometimes []/[Value], sometimes false/{value,Value}</div>

<div><br></div><div>For a function that can return 0 or 1 answers, I personally like the []/[Value] approach.</div></div>
</div><br>