[erlang-questions] Erlang 3000?

[damien morton]

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.
Can a module have multiple behaviours applied to it? What happens with
conflicts, can one function satisfy two or more behaviour requirements?

On Sun, Nov 16, 2008 at 11:07 AM, Zvi <exta7@REDACTED> wrote:

>
> Damien,
>
> look at these threads:
>
> http://www.nabble.com/List-to-proplist--to20063268.html#a20265061
>
>
> http://www.nabble.com/Hungarian-notation-for-Erlang---ETL-td14701912.html#a19822958
>
> What you suggesting can be divided into 2 tasks:
> 1. New language spec
> 2. New standard library
>
> As there is a lot of legacy products in today's Erlang/OTP, I guess OTP
> team's first priority is backward compatibility. I heard, that some
> attempts
> to fork the language failed.
> It looks like each module in stdlib was developed by people from different
> galaxies :-)
> 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 think, the best path to approach this problem, is to start writing new
> stdlib, the basis of which will be gen_collection behaviour (something like
> STL in C++ for Erlang). For simplicity it will be just common API wrappers
> for various collections ADTs in Erlang stdlib. Even if there are will be
> some performance loss, it will make code much more readable and
> maintainable.
>
> The next step is to add to gen_collection data-parallel APIs (in the style
> of plists module).
> By data parallel constructs I not only mean, usual map / fold / filter, but
> also various methods, like lookup for multiple keys or adding multiple
> key/value pairs by single function call, or operating coillections as a
> whole.
>
> For this you do not need OTP team involvent, just start open source project
> on github.
>
> Zvi
>
>
>
>
> Damien Morton-2 wrote:
> >
> > I don't suppose there's and Erlang 3000 project in the works?
> >
> > The Python people set out to create Python 3000, throwing backwards
> > compatibility out the window in favour of fixing language and library
> > design errors.
> >
> > I mentioned earlier the variety of ways that the Erlang libraries
> > signal returning a value or not. Some examples:
> >
> > 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]
> >
> > All these operations on standard ADTs are roughly equivalent, and yet
> > they have different or conflicting naming conventions, different
> > return value protocols, and different orderings of their arguments.
> >
> > While ets:lookup and dets:lookup return a tuple, one of whose members
> > is the key, gb_tree:lookup return the value of a {key,value} pair.
> >
> > gb_tree:lookup, dict:find and proplists:get_value all perform the same
> > operation, and though the return value protocol is different in each
> > case, at least the arguments are the same.
> >
> > The key asset for any well designed language or library is
> > learnability, which comes from regularity, i.e. having learned
> > something in one situation, one can apply that knowledge to similar
> > situation with a high probability of success.
> >
> > Erlang already does a lot of things differently from other languages,
> > but when every single library module does things differently from the
> > others, well, that's a lot of heterogeneity for a novice to deal with.
> >
> > I wasted an hour so so tonight trying to figure out a problem that
> > stemmed from proplists having a different argument ordering to ets - I
> > just instinctively assumed they had the same argument ordering, and
> > why shouldn't I?
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Erlang-3000--tp20518620p20520907.html
> Sent from the Erlang Questions mailing list archive at Nabble.com.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081116/68b158bb/attachment.htm>