This is a comment to lots of stuff, not just Kevins post.<br><br><div class="gmail_quote">2008/11/16 Kevin Scaldeferri <span dir="ltr"><<a href="mailto:kevin@scaldeferri.com">kevin@scaldeferri.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><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></div></blockquote><div><br>Normal in this case means false/nil/0/whatever and everything else is true. This may be practical but it is really not an 'if'. I personally think that this is better expressed by:<br>
<br>case lookup(foo) of<br>    {yes,Thing} -> ...;<br>    no -> ...<br>end<br><br>Most of the collection modules support this type of return value.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><div></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></div></blockquote><div><br>Yes, and I think that is better. It is much more explicit what you mean. <br><br>I absolutely agree that the collection modules we have have an appalling lack of consistency in their API's, most of it completely unnecessary. This is a result of how erlang was developed and grew. One could say the downside of having such a need driven development. The upside being of course that things you develop and add are really significant. This is something I will have to expand on later.<br>
</div></div><br>There are many different levels at which Erlang could be modified/enhanced, one of course would be to "just" rewrite the libraries and make them more consistent. This would be a big win just in itself.<br>
<br>Changing the funsdamentals of the language is more difficult. (duh!)<br><br>One problem is to decide what is the language and where the libraries starts. My opinion has always been that the BIF's, not necessarily just those written in C, are part of the language. Many are as fundamental as ! and receive except that they don't have a special syntax and look like normal function calls. So the module erlang is really part of the language, well much of it anyway.<br>
<br>Another problem, which somoeone also pointed to, is that many features of the language are very tightly integrated with each other and once you start poking at one you end up affecting them all. A simple example is, of course, pattern matching which is used everywhere and has the same behaviour everywhere. A much more subtle example is concurrency, messages, links/signals, receive, immutable data, error handling, ports, ... which all interact with each other and, in most cases, work coherently together and affect each other. Fiddling with them is much more difficult than at first it may seem.<br>
<br>This is one of the points I try to make in my (as yet incomplete) Erlang Rationale. Will it ever be complete? Here I see a definite problem for an Erlang 2. Not insurmountable of course, but finally someone will have to put their foot down.<br>
<br>Syntax is another problem, maybe practically even more difficult, but in one respect actually not too difficult. The main point is that the syntax and the semantics must "fit together" and support each other. This is one reason why I am not too keen on using a C/Java like syntax, it was designed for completely different semantics.<br>
<br>More thoughts later,<br><br>Robert<br><br>