Fortunately hungarian notation is just a convention, otherwise if it was in someway included in Erlang2 (or 3000) there would very soon be a new project Erlang 3, started by me. It sucks greatly.<br><br>I must honestly say that I am not that convinced in having too many generic libraries. I think that generally you know, and need to know, the representations you use. They are not equivalent even if you hide them behind a interface which tries to make them so. This is not to say that you can't make the interfaces similar if it is possible.<br>
<br>I see now in your nabble link you suggest something along these lines.<br><br>There are many levels in an language definition/standard library and a big problem is working out where the limits are. What goes in the language and what is part of a library.<br>
<br>The main problem is not the actual coding, well perhaps if you intend to rewrite the erlang VM, but working out the design and the design principles. Once these are done the coding is not that bad.<br><br>Robert<br><br>
<div class="gmail_quote">2008/11/16 Zvi <span dir="ltr"><<a href="mailto:exta7@walla.com">exta7@walla.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;">
<br>
Damien,<br>
<br>
look at these threads:<br>
<br>
<a href="http://www.nabble.com/List-to-proplist--to20063268.html#a20265061" target="_blank">http://www.nabble.com/List-to-proplist--to20063268.html#a20265061</a><br>
<br>
<a href="http://www.nabble.com/Hungarian-notation-for-Erlang---ETL-td14701912.html#a19822958" target="_blank">http://www.nabble.com/Hungarian-notation-for-Erlang---ETL-td14701912.html#a19822958</a><br>
<br>
What you suggesting can be divided into 2 tasks:<br>
1. New language spec<br>
2. New standard library<br>
<br>
As there is a lot of legacy products in today's Erlang/OTP, I guess OTP<br>
team's first priority is backward compatibility. I heard, that some attempts<br>
to fork the language failed.<br>
It looks like each module in stdlib was developed by people from different<br>
galaxies :-)<br>
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>
<br>
I think, the best path to approach this problem, is to start writing new<br>
stdlib, the basis of which will be gen_collection behaviour (something like<br>
STL in C++ for Erlang). For simplicity it will be just common API wrappers<br>
for various collections ADTs in Erlang stdlib. Even if there are will be<br>
some performance loss, it will make code much more readable and<br>
maintainable.<br>
<br>
The next step is to add to gen_collection data-parallel APIs (in the style<br>
of plists module).<br>
By data parallel constructs I not only mean, usual map / fold / filter, but<br>
also various methods, like lookup for multiple keys or adding multiple<br>
key/value pairs by single function call, or operating coillections as a<br>
whole.<br>
<br>
For this you do not need OTP team involvent, just start open source project<br>
on github.<br>
<br>
Zvi<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
<br>
Damien Morton-2 wrote:<br>
><br>
> I don't suppose there's and Erlang 3000 project in the works?<br>
><br>
> The Python people set out to create Python 3000, throwing backwards<br>
> compatibility out the window in favour of fixing language and library<br>
> design errors.<br>
><br>
> I mentioned earlier the variety of ways that the Erlang libraries<br>
> signal returning a value or not. Some examples:<br>
><br>
> proplists:get_value(Key, List) -> undefined | Value<br>
><br>
> dict:find(Key, 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>
><br>
> All these operations on standard ADTs are roughly equivalent, and yet<br>
> they have different or conflicting naming conventions, different<br>
> return value protocols, and different orderings of their arguments.<br>
><br>
> While ets:lookup and dets:lookup return a tuple, one of whose members<br>
> is the key, gb_tree:lookup return the value of a {key,value} pair.<br>
><br>
> gb_tree:lookup, dict:find and proplists:get_value all perform the same<br>
> operation, and though the return value protocol is different in each<br>
> case, at least the arguments are the same.<br>
><br>
> The key asset for any well designed language or library is<br>
> learnability, which comes from regularity, i.e. having learned<br>
> something in one situation, one can apply that knowledge to similar<br>
> situation with a high probability of success.<br>
><br>
> Erlang already does a lot of things differently from other languages,<br>
> but when every single library module does things differently from the<br>
> others, well, that's a lot of heterogeneity for a novice to deal with.<br>
><br>
> I wasted an hour so so tonight trying to figure out a problem that<br>
> stemmed from proplists having a different argument ordering to ets - I<br>
> just instinctively assumed they had the same argument ordering, and<br>
> why shouldn't I?<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
><br>
<br>
</div></div><font color="#888888">--<br>
View this message in context: <a href="http://www.nabble.com/Erlang-3000--tp20518620p20520907.html" target="_blank">http://www.nabble.com/Erlang-3000--tp20518620p20520907.html</a><br>
Sent from the Erlang Questions mailing list archive at Nabble.com.<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>