<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 15, 2008, at 6:46 PM, Robert Virding wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">2008/11/16 Kevin Scaldeferri <span dir="ltr"><<a href="mailto:kevin@scaldeferri.com">kevin@scaldeferri.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d"><br> </div>Quite honestly, I would say that the situation is worse in Erlang than<br> most dynamically typed languages, because of:<br> <br> a) the existence of symbols,<br> b) the lack of a canonical undef or nil object, and<br> c) to a lesser degree, the strangeness of the if statement<br> <font color="#888888"></font></blockquote><div><br>I don't understand your reasons at all:<br><br>Why do you want/need an undef or nil object in language where everything has a value? And where you have immutable data?</div></div></blockquote><div><br></div><div>Perhaps I was overly terse. I was not saying that any of the above are necessarily bad, but simply that they contribute to the situation where there are many modules with interfaces which are similar, but not quite the same. I.e. the complaint in the original email:</div><div><br></div><div><blockquote type="cite" class=""><span class="Apple-style-span" style="color: rgb(0, 0, 0); ">proplists:get_value(Key, List) -> undefined | Value<br><br><a href="dict:find(Key">dict:find(Key</a>, Dict) -> {ok, Value} | error<br><br>gb_tree:lookup(Key, Tree) -> {value, Val} | none<br><br>dets:lookup(Name, Key) -> [Object] | {error, Reason}<br><br>ets:lookup(Tab, Key) -> [Object]<br></span></blockquote><br></div><div>and the statement that I was responding to, but that you eliminated from the quote:</div><div><br></div><div><blockquote type="cite" class=""><span class="Apple-style-span" style="color: rgb(0, 0, 0); ">One of the problem, that Erlang is dynamicaly-typed language, and module<br>writer use whatever atoms s/he want (i.e ok, done, ping, pong, pang, error,<br>etc.), when in statically-typed language you return boolean, with only two<br>known values.<br><br>Anyway, you can see here the difference between languages, which require<br>some discipline and those which don't. It very hard, to write libraries like<br>this in Java or C++ (but very easy in Perl or other scripting languages).<br></span></blockquote><br></div><div><br></div><div>I was saying that, contrary to this statement, other dynamic languages do not suffer this particular problem. It seems to me that one reason is that most of these languages have a null/undef/nil entity which is the natural thing to return when a lookup fails. Even in languages like Ruby which also have symbols/atoms, one would never return :error or :none or what have you, because nil is available.</div><div><br></div><div><br></div><div><blockquote type="cite">Many complain about the if *expression* but I don't really understand why it warrants so much interest. I personally find that I don't use it much anyway, and that because I don't *need* to use it. I find that having pattern matching has changed my style of coding. I just checked my code for LFE and I found that where I most use a "tradional" if is is my checker module where I only check and don't produce anything.<br></blockquote><br></div><div>With regards to my point (3), what I am saying is that in languages with a "normal" if-statement, one often writes something like:</div><div><br></div><div>if (thing = lookup(foo)) {</div><div> ... do stuff with the thing...</div><div>} else {</div><div> ... it wasn't there</div><div>}</div><div><br></div><div>Of course, this relies on (a) having an if-statement that works like this, and (b) nil/undef/null being false in boolean context. Neither is the case in Erlang, so one instead tends to use a case, and it doesn't really matter if the return value of lookup is useful in boolean context.</div><div><br></div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div><br>I honesty don't see how this can make it difficult to write libraries. I have written quite a few and that was not the problem in writing them.<br></div></div></blockquote></div><br><div>I did not say anything of the sort. I was saying that these may be factors that contribute to there not being a single, natural interface for this class of functions.</div><div><br></div><div><br></div><div>-kevin</div><div><br></div><div><br></div></body></html>