[erlang-questions] Erlang 3000?

[Kevin Scaldeferri]

On Nov 15, 2008, at 6:46 PM, Robert Virding wrote:

> 2008/11/16 Kevin Scaldeferri <kevin@REDACTED>
>
> Quite honestly, I would say that the situation is worse in Erlang than
> most dynamically typed languages, because of:
>
> a) the existence of symbols,
> b) the lack of a canonical undef or nil object, and
> c) to a lesser degree, the strangeness of the if statement
>
> I don't understand your reasons at all:
>
> Why do you want/need an undef or nil object in language where  
> everything has a value? And where you have immutable data?

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:

> proplists:get_value(Key, List) -> undefined | Value
>
> dict:find(Key, Dict) -> {ok, Value} | error
>
> gb_tree:lookup(Key, Tree) -> {value, Val} | none
>
> dets:lookup(Name, Key) -> [Object] | {error, Reason}
>
> ets:lookup(Tab, Key) -> [Object]

and the statement that I was responding to, but that you eliminated  
from the quote:

> One of the problem, that Erlang is dynamicaly-typed language, and  
> module
> writer use whatever atoms s/he want (i.e ok, done, ping, pong, pang,  
> error,
> etc.), when in statically-typed language you return boolean, with  
> only two
> known values.
>
> Anyway, you can see here the difference between languages, which  
> require
> some discipline and those which don't. It very hard, to write  
> libraries like
> this in Java or C++ (but very easy in Perl or other scripting  
> languages).


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.


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

With regards to my point (3), what I am saying is that in languages  
with a "normal" if-statement, one often writes something like:

if (thing = lookup(foo)) {
   ... do stuff with the thing...
} else {
  ... it wasn't there
}

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.


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

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.


-kevin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081115/7d6d47e3/attachment.htm>