As you suggest, the 'minimal' change is to wrap the current set of collections and create a set of behaviours to regularise naming. From this a set of library guidelines could be born to guide other efforts in other modules.<div>
<br></div><div>Can a module have multiple behaviours applied to it? What happens with conflicts, can one function satisfy two or more behaviour requirements?<br><br><div class="gmail_quote">On Sun, Nov 16, 2008 at 11:07 AM, Zvi <span dir="ltr"><<a href="mailto:exta7@walla.com">exta7@walla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>
</div></div><div class="Ih2E3d">> _______________________________________________<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><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></div>