[erlang-questions] Erlang 3000?
damien morton
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-q...@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Robert Virding
Robert again
Zvi
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
--
View this message in context: http://www.nabble.com/Erlang-3000--tp20518620p20520907.html
Sent from the Erlang Questions mailing list archive at Nabble.com.
Kevin Scaldeferri
On Nov 15, 2008, at 4:07 PM, Zvi wrote:
> 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).
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
-kevin
Steve Davis
On Nov 15, 6:07 pm, Zvi <ex...@walla.com> wrote:
> What you suggesting can be divided into 2 tasks:
> 1. New language spec
> 2. New standard library
Of course 1.is vastly harder than 2.
My estimate is that writing and getting consensus on 1 would indeed
take until 3000AD.
:)
Robert Virding
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.
I see now in your nabble link you suggest something along these lines.
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.
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.
Robert
Steve Davis
> 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
/s
damien morton
Robert Virding
Of course 1.is vastly harder than 2.
On Nov 15, 6:07 pm, Zvi <ex...@walla.com> wrote:
> What you suggesting can be divided into 2 tasks:
> 1. New language spec
> 2. New standard library
My estimate is that writing and getting consensus on 1 would indeed
take until 3000AD.
At least! :-) Seriously I don't think you can aim for complete consensus, you will never get it. You need to start out with some form of rationale which lays down the basic ideas/principles for the new erlang, and explains the reasons behind them. This is something which, unfortunately, we never did.
Once this is done it is easier to design and develop the system.
Robert
damien morton
Robert Virding
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?
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.
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.
Robert
Robert Virding
That argument ordering is different and that sometimes the thing worked upon comes first, or last, or sometimes even in the middle is unfortunate. The different, or rather inconsistent, ways of indicating success/failure is also unfortunate.
Reworking Erlang to fix many of these errors would probably worth the effort, though it might split the user group. One could also fix the syntax, although making it look more like C#/Java would probably be last on my list of priorities, if it ever got there in the first place. I mean the idea is to look forwards and try and get rid of old blemishes of the past and not import someone elses old crud.
It would also be fun, though I think it would be more difficult than many believe.
Robert
Steve Davis
> therefore, far better, to change oneself than the language.
I am coming around to that conclusion. I recently understood that whilst
I had various initial concerns, I honestly couldn't think of a "better
way of doing things" once I'd really thought through all the angles.
For a "certified Java professional", this has all been a bit of a
culture shock. So yes -- I too realize that it is (mostly) me that has
needed/does need to change.
Erlang/OTP may not have had a cathedral-like architectural plan but it
does have something buried in each line of library code that, while
intangible, is **much more important** - practical real-world experience.
damien morton
> You have mentioned a very real problem, although some of the things you
> point out are actually justified. For example ets/dets explicitly handle
> tuples where one of the elements is the key while dict/orddict/gb_trees work
> with separate keys and values so a difference here is expected. It is a pity
> that gb_trees does not have a dict compatible api where it is possible.
> That argument ordering is different and that sometimes the thing worked upon
> comes first, or last, or sometimes even in the middle is unfortunate. The
> different, or rather inconsistent, ways of indicating success/failure is
> also unfortunate.
One of their library designers, Rico Mariani, had this to say:
The flip side of this is that it must not only be easy to
use the API, but it must be easy to use the API in the best possible way.
Think carefully about what patterns you offer and be sure that the most natural
way to use your system gives results that are correct, is secure against
attacks, and has great performance. Make it hard to do things the wrong
way.
A few years ago I wrote this:
The Pit of Success: In stark contrast to a summit, a peak, or a journey
across a desert to find victory through many trials and surprises, we want
our customers to simply fall into winning practices by using our platform
and frameworks. To the extent that we make it easy to get into trouble we
fail.
True productivity comes from being able to easily create great products—
not from being able to easily create junk. Build a pit of success.
> Reworking Erlang to fix many of these errors would probably worth the
> effort, though it might split the user group. One could also fix the syntax,
> although making it look more like C#/Java would probably be last on my list
> of priorities, if it ever got there in the first place. I mean the idea is
> to look forwards and try and get rid of old blemishes of the past and not
> import someone elses old crud.
> It would also be fun, though I think it would be more difficult than many
> believe.
Kevin Scaldeferri
2008/11/16 Kevin Scaldeferri <ke...@scaldeferri.com>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?
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]
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).
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.
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.
damien morton
damien morton
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.
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.
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.
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.
Valentin Micic
A natural question at this point (at least for me) would be: Why do we want to change the language? I'll dare to put forward a view that claims that there is *nothing wrong with ERLANG*. My justification for this view is as follows:
If you use ERLANG as much as I do, sooner or later you have to realize that it is far easier… well, if not easier than – profitable and more useful; therefore, far better, to change oneself than the language. It is true: whenever I hit the wall, all I had to do was to think a bit differently (*) and I’d be on a high ground again.
So, why indeed do we try to change the language? If the goal is to make it a better, we should stick to what worked so far – gradual evolution as opposed to change-the-syntax-and-everything-but-vm-revolution.
If the purpose is to gain the “masses” (**), as I understood it once, well, no amount of changes to the language will help. For that one just need money and marketing – hence lots of money.
BR.
V.
(*) Mind you, in some other environments (say, languages, run-times, etc.) no amount of thinking differently would help.
(**) Or critical mass, which is, IMHO, just euphemism for masses.
----- Original Message -----
Zvi
Damien Morton-2 wrote:
>
> 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.
>
Yes, this is what I proposed.
This is the fastest way to start prototyping new stdlib, for the begining I
propose to use new module names (i.e. for example gc_set instead set,
gc_dict, instead dict , etc., where "gc_" perfix mean gen_collection), i.e.
to not interfere with legacy code.
I have 2 ideas here:
1. Maybe there is a reason from the beginning to have 2 collection
behaviours, like in Python:
a. gen_mapping (for dict, ets, dets, i.e. any key=>[value] mapping, maybe
even funs)
b. gen_sequence (for list, tuple, array, set, ordset, etc.). In some
languages you may use index as a key - so maybe everything can be
gen_mapping?
2. Use parametrized types, to specify ADT implementation details / policies.
For example in case of distributed/SMP map/fold , using something as plists
"malt" (i.e. how to split tasks between cores/nodes or just use sequential
code - this is just example).
Zvi
Damien Morton-2 wrote:
>
> Can a module have multiple behaviours applied to it? What happens with
> conflicts, can one function satisfy two or more behaviour requirements?
>
I don't know
--
View this message in context: http://www.nabble.com/Erlang-3000--tp20518620p20524858.html
damien morton
This is the fastest way to start prototyping new stdlib, for the begining I
propose to use new module names (i.e. for example gc_set instead set,
gc_dict, instead dict , etc., where "gc_" perfix mean gen_collection), i.e.
to not interfere with legacy code.
I have 2 ideas here:
1. Maybe there is a reason from the beginning to have 2 collection
behaviours, like in Python:
a. gen_mapping (for dict, ets, dets, i.e. any key=>[value] mapping, maybe
even funs)
b. gen_sequence (for list, tuple, array, set, ordset, etc.). In some
languages you may use index as a key - so maybe everything can be
gen_mapping?
2. Use parametrized types, to specify ADT implementation details / policies.
For example in case of distributed/SMP map/fold , using something as plists
"malt" (i.e. how to split tasks between cores/nodes or just use sequential
code - this is just example).
mats cronqvist
> Is there anything you can do with an if statement that cant be done with a
> case statement?
no.
and there is nothing you can do with a 'case' that you can't do with
a 'try'.
i think a reasonable goal for Erlang v2 (Etwo?) is to get rid of
cruft like 'if', 'case', 'catch', 'and', 'or', the old guards
etc. and perhaps provide a more consistent API to the libraries (in
a new namespace?)
mats
Kevin Scaldeferri
On Nov 15, 2008, at 2:47 PM, damien morton wrote:
> Though there were worries that the Python 3000 effort might split
> the community, that doesn't seem to have happened. Tools have been
> produced that make porting to py3000 possible, and I understand that
> the language changes are relatively modest, removing the most
> glaring of language warts, and regularising and reorganising
> libraries.
>
I don't follow what's going on in the Python community, but just as a
counterpoint, there seems like a strong possibility that Perl 6 will
split the community. Quite bizarrely, the closer a complete, working
implementation gets, the louder some people become about their opinion
that it will never be a finished or viable platform.
-kevin
damien morton
Robert Virding
Robert
I created a forum on Google Moderator for collecting together ideas on Erlang 3000.The forum is called Next(Erlang) and can be found at http://moderator.appspot.com/#15/e=bbc4&t=b355Google Moderator is a combination of a discussion group with up/down voting on particular discussions.
Zvi
don't you think it should be
Erlang2 = erlang2:next(Erlang).
{ok, Erlang2} = erlang2:next(Erlang).
assuming, that erlang2 module is autoimported, then
{ok, Erlang2} = next(Erlang).
or just
next(Erlang)
(i.e. like C++ or [incr Tcl] ;-)
ok, moving to google groups...
Zvi
--
View this message in context: http://www.nabble.com/Erlang-3000--tp20518620p20527337.html
Sent from the Erlang Questions mailing list archive at Nabble.com.
_______________________________________________
Robert Virding
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}
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:
case lookup(foo) of
{yes,Thing} -> ...;
no -> ...
end
Most of the collection modules support this type of return value.
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.
Yes, and I think that is better. It is much more explicit what you mean.
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.
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.
Changing the funsdamentals of the language is more difficult. (duh!)
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.
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.
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.
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.
More thoughts later,
Robert
damien morton
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.
More thoughts later,
Kevin Scaldeferri
2008/11/17 Robert Virding <rvir...@gmail.com>
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.
More thoughts later,Another correspondent pointed out that the scope of the changes in Perl 6 is provoking Shock and Awe is some of Perl community - the changes are so extensive that the language is barely recognisable.
mats cronqvist
>
> Why do you want/need an undef or nil object in language where everything has a
> value? And where you have immutable data?
so you think initializing record fields to 'undefined' is state of
the art?
> 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.
you don't use it because it's cruft, and people complain about it
because they dislike cruft.
mats
damien morton
"Robert Virding" <rvir...@gmail.com> writes:
> Why do you want/need an undef or nil object in language where everything has a
> value? And where you have immutable data?
you don't use it because it's cruft, and people complain about it
> 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.
because they dislike cruft.
Robert Virding
So here's a question: Are there any examples of "if" statements that would be awkward or difficult to express using a "case" statement?
There is never a case when it would difficult to use case, just some cases where it be awkward or look really strange:
case true of
true when X > 39 -> ...;
true -> ...
end
instead of
if X > 39 -> ...;
true -> ...
end
Robert
Håkan Stenholm
>
> "Robert Virding" <rvir...@gmail.com <mailto:rvir...@gmail.com>>
patterns - e.g. something like the to_upper code below:
to_upper_char(C) when is_integer(C) ->
if
$a =< C, C =< $z -> C - 32;
16#E0 =< C, C =< 16#F6 -> C - 32;
16#F8 =< C, C =< 16#FE -> C - 32;
true -> C
end.
Yes I know that this could be written as:
to_upper_char(C) when is_integer(C) ->
case ($a =< C andaslo C =< $z) orelse
(16#E0 =< C andalso C =< 16#F6) orelse
(16#F8 =< C andalso C =< 16#FE) of
true -> C - 32;
false -> C
end.
but lets assume that each branch needs to do something different, so we
must either use nested cases or have multiple function clauses (one for
each condition) to check all the guards.
"if"s tend to be convenient in numerical code - like checking for
multiple numeric ranges (as above) or to avoid silly things like:
case .... of
_ when ... -> ...
_ when ... -> ...
_ when ... -> ...
...
end
instead of:
if
... -> ...
... -> ...
... -> ...
...
end
>
>
> ------------------------------------------------------------------------
damien morton
Of the ones I looked at, 90% or so were your basic if/else type statement, e.g:
if
Parent =:= self() ->
undefined;
true ->
Cursor = #qlc_cursor{c = {self(), Parent}},
fun() -> delete_cursor(Cursor) end
end,
A portion of the remaining 10% were more complicated logic, such as:
lookup_all(Key, [P | Ps]) ->
if is_atom(P), P =:= Key -> [{Key, true} | lookup_all(Key, Ps)];
tuple_size(P) >= 1, element(1, P) =:= Key -> [P | lookup_all(Key, Ps)];
true -> lookup_all(Key, Ps)
end;
And a further portion of the remaining 10% were of the form you
described, i.e. sequences of range tests.
I see that there is an EEP for an is_between() BIF, with mention of
supporting boolean expressions of the form "A < B < C", which are a
wonderful convenience.
I find myself wondering if "case" and "if" can be unified somehow.
Consider these two hypothetical statements, which are equivalent:
A=foo(),
case
{B,C}=A, is_list(B) -> do_list(B);
-> do_other()
end
case foo() of
{B,C}, is_list(B) -> do_list(B);
-> do_other()
end
In the first statement, the attempted pattern match {B,C}=A is treated
the same as a guard. Failure to match is treated the same as a failed
guard.
In the second statement, the value to match against is implicit.
Hmm, needs more thought.
On Mon, Nov 17, 2008 at 11:44 AM, Håkan Stenholm
<hokan.s...@bredband.net> wrote:
Bengt Kleberg
Perhaps somebody would care to post another example since this one is
very easy to make un-strange:
case X > 39 of
true ->
false ->
end
bengt
Those were the days...
EPO guidelines 1978: "If the contribution to the known art resides
solely in a computer program then the subject matter is not
patentable in whatever manner it may be presented in the claims."
On 2008-11-17 01:36, Robert Virding wrote:
> 2008/11/17 damien morton <dmo...@bitfurnace.com
> <mailto:dmo...@bitfurnace.com>>
> ------------------------------------------------------------------------
Bengt Kleberg
You could also add that the return values upon success are unnecessarily
different:
ets => true
mnesia => ok
bengt
Those were the days...
EPO guidelines 1978: "If the contribution to the known art resides
solely in a computer program then the subject matter is not
patentable in whatever manner it may be presented in the claims."
Michael T. Richter
> therefore, far better, to change oneself than the language.
I am coming around to that conclusion. I recently understood that whilst I had various initial concerns, I honestly couldn't think of a "better way of doing things" once I'd really thought through all the angles.
|
-- Michael T. Richter <ttmri...@gmail.com> (GoogleTalk: ttmri...@gmail.com) I have to wonder why people think that when they can't manage local personnel within easy strangling and shooting distance, then they can manage personnel thousands of miles away that have different languages, cultures, and business rules. (Joe Celko) |
Vance Shipley
} Perhaps somebody would care to post another example
if
HaveMoney and Hungry ->
buy_food();
HaveMoney and not Hungry ->
buy_beer();
not HaveMoney ->
work()
end
It just reads better.
As far as a new Erlang goes I'd mostly want the libraries modernized.
Now that we have try ... catch ... end it would be nice if we didn't
have to code for {ok, value} | {error, Reason} any longer.
-Vance
Kenneth Lundin
not consistent with each other
but I don't think this is a major problem for users of Erlang.
I think it is a very bad idea to start discussing a new incompatible
track of Erlang just because of this.
The Erlang community is not big enough for this yet, what we need now
is actions that stimulate the
growth of the community.
I definitely don't think the inconsistency in the tree, dict etc. APIs
is one of the most important things in this.
More important is to get more high quality reusable Open Source
components and an easy way to find these.
Also more important is to have more books and more "killer"
applications built with Erlang. Applications that draw
the attention to Erlang.
When it comes to inconsistencies in libraries and language I think the
best way is to prepare a suggestion on design rules for new API's
both for collection ADT's and in general. Then this can be used as a
basis for evolving stepwise into more consistent API's.
There are ways to evolve without breaking compatibility new functions
can easily be added and old ones can be deprecated.
New modules can also easily be added etc.
It is also very important to remember that backwards compatibility is
one of the most appreciated characteristics of Erlang. It makes it
possible for
large and huge SW projects to shift to a new major release of
Erlang/OTP with minimal work. This is essential in order to
get users to upgrade to the next release.
/Kenneth Erlang/OTP, Ericsson
Christian
<kenneth...@gmail.com> wrote:
> More important is to get more high quality reusable Open Source
> components and an easy way to find these.
> Also more important is to have more books and more "killer"
> applications built with Erlang. Applications that draw
> the attention to Erlang.
"Me too" regarding all your points.
I find that when advocating Erlang the most common question I get is
doubt about the library availability to do "things". Where "things"
are various problem domains. If it is to use established network
protocols, encryption, databases, gui...
There is a lot of "grassroots" development of libraries and
applications now, but they do not converge to one-true-place where you
can get an overview of them all. I lack a good overview of what areas
Erlang would be suitable, but where there are no libraries.
What is it that is missing to get the community to converge better?
I really liked the content on the wiki Luke Gorrie used to run, but,
after some serious downtime, it just died. I think jungerl had a
goal to be the ultimate collection of erlang libraries, but it sort of
died away when not getting any real face-to-face hackaton to learn to
know each other and together improve quality and make a great software
collection. And as usual nobody really has the time anyway. :-/
What does it take to get some community-driven subdomain sites under
the erlang.org domain (so they will get a more official appearance) ?
Will it absolutely not happen? Does it require an "ansvarig utgivare",
signing contracts and all, responsible for the content etc?
Thomas Lindgren
--- On Sun, 11/16/08, Kevin Scaldeferri <ke...@scaldeferri.com> wrote:
> 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 think this is basically a consequence of rolling out new libraries without vetting the APIs and then being semi-unable to change them once they are out. It might of course also be noted that many long-lived and popular libraries have similar problems.
Best,
Thomas
James Hague
big things that really matter are:
1. Reworking the standard libraries: sets vs. ordsets vs. gb_sets,
file_size is in filelib instead of file, reverse/1 should be
accessible without importing lists, simple modules are overrun with
rarely used cruft, separate out the simple ets from the not so simple
match specification stuff, and so on.
2. Some form of lightweight hash table outside of ets. Ideally this
would be the replacement for dict/orddict/gb_trees.
Edwin Fine
It would also be extremely useful to beef up the FAQs by combing the Erlang mailing lists and extracting some of the more interesting and complex questions and answers. Yes, we can search the lists, but it can often be very time-consuming, and sometimes one can miss the target if the right Google incantation is not invoked. If most of the answers were condensed into the FAQ it would make a big difference, especially to less experienced Erlang devotees like myself.
Thanks for a marvelous development platform, namely Erlang/OTP!
Regards,
Edwin Fine
mats cronqvist
> (I know there is a kluged up one in Emacs, but how about one that
> works across the board, not only in Emacs?).
http://en.wikipedia.org/wiki/Kludge (sic); "a clumsy or inelegant
solution to a problem"
just for the record; the emacs/distel solution is possibly the most
elegant erlang code written this millenium. at least by me :>
mats
Robert Virding
I've proposed all sorts of crackpot extensions to Erlang, but the two
big things that really matter are:
1. Reworking the standard libraries: sets vs. ordsets vs. gb_sets,
file_size is in filelib instead of file, reverse/1 should be
accessible without importing lists, simple modules are overrun with
rarely used cruft, separate out the simple ets from the not so simple
match specification stuff, and so on.
I quite agree with you here. Having inconsistent confusing libraries id difficult for everyone and is a turn-off for new comers.
2. Some form of lightweight hash table outside of ets. Ideally this
would be the replacement for dict/orddict/gb_trees.
Yes, a built-in lightweight form of dictionaries would be nice, especially if you can match on them. Something like Joe's structs or ROK's frames. However, I do not really see them as a replacement for the existing tables as I don't think you can get them both lightweight and able to efficiently handle large amounts of data. Ets is not always the best alternative for large tables.
Concerning Kenneth's post I will get to that with a proper comment. He is right, but also wrong and things do have to be fixed.
Robert
Dave Smith
Perhaps somebody would care to post another example since this one is
very easy to make un-strange:
case X > 39 of
true ->
false ->
end
true when X > 39 -> ...;
true -> ...;
Edwin Fine
;; Warning, the function `erlang-man-function' is a hack!
;; It links itself into the man code in a non-clean way. I have
;; chosen to keep it since it provides a very useful functionality
;; which is not possible to achieve using a clean approach.
;; / AndersL
damien morton
> I've proposed all sorts of crackpot extensions to Erlang, but the two
> big things that really matter are:
>
> 1. Reworking the standard libraries: sets vs. ordsets vs. gb_sets,
> file_size is in filelib instead of file, reverse/1 should be
> accessible without importing lists, simple modules are overrun with
> rarely used cruft, separate out the simple ets from the not so simple
> match specification stuff, and so on.
> 2. Some form of lightweight hash table outside of ets. Ideally this
> would be the replacement for dict/orddict/gb_trees.
Isn't dict the lightweight hashtable you are looking for? If not, what
would be the difference bewteen this lightweight hashtable and
dict/orddict/gb_trees/dict and ets?
damien morton
From: damien morton <dmo...@bitfurnace.com>
Date: Tue, Nov 18, 2008 at 9:53 AM
Subject: Re: [erlang-questions] Erlang 3000?
To: Edwin Fine <erlang-ques...@usa.net>
On Tue, Nov 18, 2008 at 4:00 AM, Edwin Fine
<erlang-ques...@usa.net> wrote:
> Completely agree with Kenneth. Any software that grows organically is going
> to have inconsistencies. Software like Erlang has usually responded to
> real-world pressures, in real-world timeframes, and has not had the luxury
> of (say) a series of long design competitions and committees like Ada did
> (and IIRC, Ada is not that widely used for all that). Some would have a sigh
> of relief that Erlang didn't go through that process! I think Erlang has
> done pretty well, and it probably really IS premature to consider
> "purifying" it while it's trying to get a strong foothold in the development
> community. I would say that higher priorities are to improve its vertical
> (multicore) scalability, make more and easier to use tools for (inter alia)
> operational control and monitoring and release management, as well as
> productivity tools like better documentation and a well-indexed "apropos"
> type facility that allows one to search for any specific function, not just
> its module (I know there is a kluged up one in Emacs, but how about one that
> works across the board, not only in Emacs?). Other areas that might be
> fertile ground include distributed security - the current cookie/short
> name/long name model is a bit limiting, and making it easier to set up and
> view traces of running code. Maybe I am just dumb, but there are parts of
> Erlang that are so arcane that I need to have notes to explain to myself how
> to use them.
The point is that designers of new libraries will look to the core
libraries for guidance on what patterns, interfaces and protocols to
follow. If the core is schizophrenic and full of entropy, growing the
language will only multiply that entropy. If the core has low-entropy,
growing the language will increase that entropy at a much slower rate.
In my opinion, there needs to be two forces applied to the
language/libraries - the force of growth and the force of reducing
entropy. Refactoring is the entropy reduction strategy of choice, and
if we are careful, that refactoring could be automated.
Vance Shipley
into packages? That seemed like an interesting branch.
-Vance
Robert Virding
Vance Shipley
} What do you mean by packages?
The namespace packages. I recall seeing the libraries stuffed
into packages to group things like maybe erlang.bif:link/1.
damien morton
throws an error currently, so it wouldnt break any code to do this.
damien morton
http://moderator.appspot.com/#15/e=bbc4&t=bbc5
"arbitrarily deep hierarchies of modules [with name-space protection
for functions], instead of a flat global module names"
Robert Virding
Robert
On Tue, Nov 18, 2008 at 01:32:17AM +0100, Robert Virding wrote:
} What do you mean by packages?
Vance Shipley
} No way, don't like packages.
Well somebody around here was working on that at some time.
-Vance
To be clear: http://erlang.org/doc/man/packages.html
Robert Virding
Also, Robert, I was interested in your disagreement with Kenneth (RE:
the need for an Erlang refactor) you said you would put together... is
that still coming?
Yes, but it will have to wait until tomorrow, too late now. And I also agreed with him as well.
Robert
Robert Virding
Robert Virding wrote:
> Yes, but it will have to wait until tomorrow, too late now. And I also
> agreed with him as well.
Not worried about the delay, just hoping to read it. The fact you agreed
with him on some aspects and not others (as do I) is what intrigues me.
I am curious to know how much consensus there might be on it.
Not enough to stop a good fight. :-)
Robert
Bob Ippolito
> On Tue, Nov 18, 2008 at 02:10:19AM +0100, Robert Virding wrote:
> } No way, don't like packages.
>
> Well somebody around here was working on that at some time.
I think the problem is that packages were implemented in an
undesirable way. Erlang does have a package system, but AFIAK nobody
uses it or likes it.
What I don't like about the package system is that any time you use it
you need to do a bunch of explicit stuff to use standard modules (e.g.
-import(list) or something).
-bob
Dave Smith
Benjamin Tolputt
> Yes, but it will have to wait until tomorrow, too late now. And I also
> agreed with him as well.
Not worried about the delay, just hoping to read it. The fact you agreed
with him on some aspects and not others (as do I) is what intrigues me.
I am curious to know how much consensus there might be on it.
--
Regards,
Benjamin Tolputt
Analyst Programmer
This email and any files transmitted with it are confidential to the
intended recipient and may be privileged. If you have received this
email inadvertently or you are not the intended recipient, you may not
disseminate, distribute, copy or in any way rely on it. Further, you
should notify the sender immediately and delete the email from your
computer. Whilst we have taken precautions to alert us to the presence
of computer viruses, we cannot guarantee that this email and any files
transmitted with it are free from such viruses.
Dave Smith
What I don't like about the package system is that any time you use it
you need to do a bunch of explicit stuff to use standard modules (e.g.
-import(list) or something).
Bob Ippolito
Eh. The easier way would be to assume that all module usage is
absolute, unless you explicitly ask for a relative module.
Benjamin Tolputt
> No way, don't like packages.
Yeah, I remember the discussions on it. *laugh*
In the scheme of all things Erlang though, I wouldn't classify it as
something stopping adoption or causing confusion. I like the "concept"
of packages or, more specifically, being able to write code such as
"namespace1.module2:foo(bar)" without having to quote the atoms. But as
far as next(erlang) is concerned, it could be on the back-burner
compared to inconsistent interfaces and the like.
Also, Robert, I was interested in your disagreement with Kenneth (RE:
the need for an Erlang refactor) you said you would put together... is
that still coming?
--
Regards,
Benjamin Tolputt
Analyst Programmer
This email and any files transmitted with it are confidential to the
intended recipient and may be privileged. If you have received this
email inadvertently or you are not the intended recipient, you may not
disseminate, distribute, copy or in any way rely on it. Further, you
should notify the sender immediately and delete the email from your
computer. Whilst we have taken precautions to alert us to the presence
of computer viruses, we cannot guarantee that this email and any files
transmitted with it are free from such viruses.
_______________________________________________
Maxim Treskin
The main approach in programming on Erlang is bunch of well defined isolated applications running on node(s), i.e. yaws+mnesia+kernel for web and so on. Each application contains number of modules and names and functions of these modules is unique through whole application. Moreover these names is very simple due to deep hierarhies of module absence in Erlang.
I strongly against of functions like web.common.http.uri.util:escape/1.
--
Maxim Treskin
Dave Smith
Bengt Kleberg
One good (IMHO) critique of packages, as they are currently implemented,
is found here:
http://www.erlang.org/pipermail/erlang-questions/2006-November/023782.html
On the other hand, packages, even as they are currently implemented,
would make it possible to rewrite the libraries. That could also be done
with the '.' replaced with '_' so it is not a very good argument. But I
really would like to rewrite them.
bengt
Those were the days...
EPO guidelines 1978: "If the contribution to the known art resides
solely in a computer program then the subject matter is not
patentable in whatever manner it may be presented in the claims."
On 2008-11-18 03:25, Dave Smith wrote:
>
> So, what's the status of packages?
>
> Robert, Is you're objection to this particular implementation or is
> there some argument against an hierarchical module namespace in general?
>
> 2008/11/17 Vance Shipley <van...@motivity.ca <mailto:van...@motivity.ca>>
>
> On Tue, Nov 18, 2008 at 02:10:19AM +0100, Robert Virding wrote:
> } No way, don't like packages.
>
> Well somebody around here was working on that at some time.
>
> -Vance
>
> To be clear: http://erlang.org/doc/man/packages.html
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>
>
> ------------------------------------------------------------------------
Benjamin Tolputt
> I think the problem is that packages were implemented in an
> undesirable way. Erlang does have a package system, but AFIAK nobody
> uses it or likes it.
>
> What I don't like about the package system is that any time you use it
> you need to do a bunch of explicit stuff to use standard modules (e.g.
> -import(list) or something).
>
For me it would be enough if I could do the following:
------------------
%% File: namespace1.module1.erl
-module(namespace1.module1).
%% Namespace for this file - probable not required if I can simply name
the file appropriately
-namespace(default, namespace1).
-namespace(using, namespace1.module2).
-export([foo/0]).
foo()->
module2:bar(), %% This will actually use namespace1.module2:bar()
ok.
------------------
%% File: namespace1.module2.erl
-module(namespace1.module2).
%% Namespace for this file - probable not required if the compiler can
work it out from filename
-namespace(default, namespace1).
-export([bar/0]).
bar()->
file:get_cwd(). %% As there is no "namespace1.file.erl" module, this
will use the standard file:get_cwd() fun
------------------
This would give standard behaviour for modules not within the namespace
and for where the code never uses the "-namespace(...)" (such as all
existing code).
>From the look of it - it could be implemented simply by replacing any
occurence of "module2" to "namespace1.module2" in the compilation phase.
There are issues with the passing around of atoms though (for example,
say I pass the atom tuple {module2, bar} to code outside the namespace
and it then uses it to call module2:bar - what happens?).
There is a bit of thought needed before this would go ahead, but I don't
think the parties most needed in the discussions are interested in
implementing this at the moment.
--
Regards,
Benjamin Tolputt
Analyst Programmer
This email and any files transmitted with it are confidential to the
intended recipient and may be privileged. If you have received this
email inadvertently or you are not the intended recipient, you may not
disseminate, distribute, copy or in any way rely on it. Further, you
should notify the sender immediately and delete the email from your
computer. Whilst we have taken precautions to alert us to the presence
of computer viruses, we cannot guarantee that this email and any files
transmitted with it are free from such viruses.
_______________________________________________
Joe Armstrong
It is (of course) highly desirable to have a large set of libraries
that are written in a consistent and predictable manner - the problem
is how to we get there?
I have actually been building a library that one day I hope to
publish - it's got 70 modules in it so far ...
Now there are some problems in building a large library.
For reasons of consistency all the library modules have to follow
some common programming rules - these rules have to encapsulate what
we think is good style and best practise (whatever that means)
Let's now imagine what happens when you build a large library.
- you write the first module - no problems
- you write the second module - ...
- ...
- you write the N'th module now you realize the design of
some functions you want to call in module 6 was wrong.
What do you do? - stop writing module N and go back to 6.
In re-writing 6 you discover that 2 was wrong, what do you
do? stop writing module 6 and go back to 2 ????
This is bad enough when one person writes all the code
but when somebody else wrote the earlier code the problem
gets *much* worse.
- you've been a bit lazy with the documentation so you decide to
write some decent documentation. When you get started you realise
that what you are describing is a mess - it would be much easier
if it had been written "like this" so you write the documentation
describing what the code should have been - then go back and
hack the code.
- You've written the code but not much meta data. The meta data
is the stuff describing the code (the type signatures, documentation
etc.)
- when the code base is small there is no problem (put it all in one
directory) - as it grows you wish you'd organised it better
so you put it in several directories. As it gets very large you
realise that putting it into several directories makes doesn't
help - there are so many directories that you can't find the code
anyway - the only way to find things is to hope that Google has
indexed it.
- you wish you had added more meta data to your code (to allow
accurate indexing)
*hypothesis* as code bases get larger the most important thing
is the quality of the meta data - not the data. The meta data
determines our ability to find stuff - if we can't find stuff
it does not matter how good it is.
So how do I organise my 70 module library?
- all code in one directory
- whenever I find an inconsistency in an earlier module I go
back and rewrite the original code (and everything that calls it)
One thing I find *very* useful is to put all small pure functions
that are generally useful in the *same* module.
<< There is a problem - functions have to belong to modules - but there are a
*lot* of very small pure functions that can't really be said to belong to
any particular module solution: Put them all in lib_extra.>>
<<
I also use inheritance (If I don't want to touch an existing module) I
write.
-module(xx).
-inherit(old_mod).
-export([....])
This is just a simple parse transform, it makes stub functions for all the
exported functions in old_mod that are not in xx. if xx has a new version
of a routine in old_mod it will override that function.
Why do it like this? - because I may not want to modify old_mod (if I have
distributed it).
>>
At the end of the day I believe the meta data to be far more important
than the code. getting the APIs right is the difficult bit.
If anybody else tells me "I have to read the code to see what it does"
I will scream - whenever I read code the following happens:
- I don't understand it
- I start to understand it
- I get an overwhelming desire to rewrite it
Reading code to discover what it does is a sign of incompleteness. A
program is not complete until it has passed all its tests and has good
documentation.
If you have to read the code to figure out what the program does then the
project is incomplete.
We should really have a programming rule. The APIs and code should be
in two *different* files - the reviewers should not be allowed to read
the code (This is a *very good reason* why code and documentation
should not be allowed in the same file)
(( If code and documentation are allowed in the same file, then the
person editing the documentation might accidentally read the code and
thus describe the code *and not the interface* (which is a completely
different thing))
Flame on: reading the code tells you what the code does (if you can
understand it - but not "what it is *supposed* to do".
So before we rush off and write the ultimate set of modules - can we
try to write just ONE module in as beautiful way as possible.
This module could serve as the great progenitor - it should be
well written, well documented, with well thought-out meta data.
*I know of no such module* (and in case you were wondering, my 70 module
library is *not* beautifully annotated with meta-data).
There is also the problem of style and taste - personally I favor the
"one author many critical eyes" approach. When my Erlang book went to
beta I got thousands of eyes staring at every line I'd written - this
feedback was fantastic (thanks everybody) and significantly improved
the quality.
I don't believe in a group of people "voting" for features in code -
But I do believe in readers and writers. Few writers of code (who make the
decisions) but many readers.
If we set this thong up I will donate parts of my library to the
project - I've written a new XML thing that is rather pretty (I think)
- it lacks test cases (because it's right :-) and meta data (because
I'm lazy) and documentation (because we don't have a good
documentation system in place)
I think it would be great to set up an infrastructure for writing good
quality community code - the things we have to setup are:
- programming rules
- review process
- distribution process
- production process
We need methods for producing drop-dead-beautiful documentation
(in PDF, HTML, ...) - think "book quality"
We need an agreement on meta data.
We need to an agreement on the distribution process.
We need an infrastructure. The genius of the Wikipedia is that it is
an organisational form that allows a lot of people to contribute by
doing a little. Correcting a spelling mistake, asking a question,
replying to a question has enormous power when done by hundreds or
thousands of people.
So here we have it - lots of jobs to be done.
Me, I can author code, if somebody else can deign and host a web site
with SW support for the review process it would be great.
/Joe Armstrong
Vance Shipley
} What ever happened to the initiative to put kernel and stdlib
} into packages? That seemed like an interesting branch.
OK, that recollection was driving me nuts so I tried to find
where I had gotten that impression and I found it right in the
Erlang/OTP distribution.
erts/emulator/beam/bif.tab:
[...]
# Add new BIFs to the end of the file. Do not bother adding a "packaged
# BIF name"
# (such as 'erl.lang.number'); if/when packages will be supported we
# will add
# all those names.
[...]
bif erlang:binary_to_term/1
bif 'erl.lang.binary':to_term/1 ebif_binary_to_term_1
Apparently some folks in the group thought packages might find legs
at one point.
Richard O'Keefe
On 18 Nov 2008, at 1:50 pm, Vance Shipley wrote:
> The namespace packages. I recall seeing the libraries stuffed
> into packages to group things like maybe erlang.bif:link/1.
There are several reasons why I don't want anything like that to
happen.
First, we do not yet have a reasonable package system to
put things into. We have a rather pointless and confusing
'flat namespace with dots in it' scheme, but it has problems
and limitations which have been gone over in the mailing list
several times.
Second, be careful what you wish for. You might get it!
I'm reminded of Piet Hein's
THE OPPOSITE VIEW
For many system shoppers it's
a good-for-nothing system
that classifies as opposites
stupidity and wisdom
because by logic-choppers it's
accepted with avidity:
stupidity's true opposite's
the opposite stupidity.
"The opposite stupidity" to a completely packageless system
is something like the current Haskell libraries, with their
hierarchical name spaces. A single conceptual unit in Haskell
is these days typically broken down into three or four modules
and you see stuff like this (taken from real Haskell code):
import qualified Data.ByteString as BS
import qualified Data.ByteString.Internal as BS
import qualified Data.ByteString.Unsafe as BS
These days I am seeing Haskell code with huge long lists
of imports that could have been shorter if the fashion
hadn't been for vast numbers of micro-packages.
Of course developing some feature as a cluster of modules
makes a great deal of sense, but clients should only have
to deal with a single façade module if at all possible.
In this case, breaking up the 'erlang' module appears to
offer clients no advantages.
Richard O'Keefe
On 18 Nov 2008, at 7:36 pm, Dave Smith wrote:
> The package hierarchy does not need to be deep.
This is perfectly true. But if the Java and Haskell experiences
are anything to go by, it WILL become deep whether it needs to
or not. We can confidently expect people experienced in Java to
continue using Java naming practices in Erlang. (Heck, haven't
we already seen enough pointlessly ugly baStudlyCaps trickling
into Erlang like pus from an Erebus-sized boil?)
damien morton
package.module:function
Richard O'Keefe
On 18 Nov 2008, at 10:05 am, Robert Virding wrote:
> Yes, a built-in lightweight form of dictionaries would be nice,
> especially if you can match on them. Something like Joe's structs or
> ROK's frames. However, I do not really see them as a replacement for
> the existing tables as I don't think you can get them both
> lightweight and able to efficiently handle large amounts of data.
100% agreement from me on that one.
Something that can act as a credible replacement for -record
has to be as lightweight as it can be made.
I now have a design for a 'micro-Erlang' and part of an
implementation. I can happily say that it can be very
lightweight indeed. Don't hold your breath waiting for it
to be finished, though... The design does _not_ scale to
large numbers of elements.
I'm intrigued by Joe's new library and would be interested to
hear more about it.
Masklinn
On 18 nov. 08, at 22:57, "Richard O'Keefe" <o...@cs.otago.ac.nz> wrote:
>
> On 18 Nov 2008, at 7:36 pm, Dave Smith wrote:
>> The package hierarchy does not need to be deep.
>
> This is perfectly true. But if the Java and Haskell experiences
> are anything to go by, it WILL become deep whether it needs to
> or not.
Python also has arbitrarily nested package, but it doesn't seem to
have that issue maybe due to it's direct physical mapping and
importing flexibility (especially in top level packages). And although
it's been slightly revised in 3000 and some people find __init__.py to
be a kludge I find the system pleasant to work with.
A sane (= not too deeply nested) example set by the standard library
might also help (the lower nesting of the java stl is already 3 levels
or so...)
Robert Virding
While I know that most of the libraries actually are quite good in spite of their APIs and that the erlang VM is very good and tested and robust it does not look like this for many people. Unless they take the time to study and test the system properly they may be scared off by what they perceive to be a sloppy and hastily put together system. Especially if they have read the same thing in some blogs.
Therefore I think it is definitely worth redoing and cleaning up many of the libraries.
Also we have against us that we don't run on the JVM, which I hold to be a real benefit of course. :-) Think of a world without last-call optimisation?
I am less worried about splitting the erlang community as I don't think that it will happen. It may be a major change but it will never be something that just pops out of the blue so I assume people will adjust and appreciate the improvements. One thing we have to do to help the community is to make a proper language spec and rationale so that people can really know what erlang is and how it is supposed to work. This is a necessary prerequisite for new implementations other than the BEAM, and if erlang is successful these will come.
While we are talking about change, I think a few syntax changes would be beneficial but I don't think they can ever be enough to appease the real syntax whiners. I separate those who complain about the syntax into whiners, those who whine about it not being like java, and those have actually tried it and come with serious criticism. This is not why I would like to make some changes.
Thomas Lindgren mentioned one reason why the APIs look like they do, no vetting. Another early reason is that we were concentrating on some aspects of the language, and implementing it, and often we just need a library so we hacked one together. And we still have them hanging around. An unfortunate and slightly depressing prerequisite to these reasons is that some didn't have the inclination or time to make a good API.
And I must admit I had a rather cavalier attitude to libraries before, if you need a library you write it yourself. Which probably didn't help much. :-)
I agree with Joe on how to proceed, although I think you have to release the new libraries earlier to the eager waiting public, you can't wait until you have redone the whole lost before releasing them. However you *do* need a small group to work on the guidelines and programming rules and do the initial new libraries, both as tests of the rules and as examples. The group should be small or else it is difficult to work out a clear concise set of rules and guidelines. As always the problem is not what not add but what to remove.
The funny thing is that I am probably the one who least cares if my stuff is ever used. Strange world.
That's about it for this time,
Robert
I agree that it is unfortunate that some of the library modules are
not consistent with each other
but I don't think this is a major problem for users of Erlang.
I think it is a very bad idea to start discussing a new incompatible
track of Erlang just because of this.
The Erlang community is not big enough for this yet, what we need now
is actions that stimulate the
growth of the community.
I definitely don't think the inconsistency in the tree, dict etc. APIs
is one of the most important things in this.
More important is to get more high quality reusable Open Source
components and an easy way to find these.
Also more important is to have more books and more "killer"
applications built with Erlang. Applications that draw
the attention to Erlang.
When it comes to inconsistencies in libraries and language I think the
best way is to prepare a suggestion on design rules for new API's
both for collection ADT's and in general. Then this can be used as a
basis for evolving stepwise into more consistent API's.
There are ways to evolve without breaking compatibility new functions
can easily be added and old ones can be deprecated.
New modules can also easily be added etc.
It is also very important to remember that backwards compatibility is
one of the most appreciated characteristics of Erlang. It makes it
possible for
large and huge SW projects to shift to a new major release of
Erlang/OTP with minimal work. This is essential in order to
get users to upgrade to the next release.
/Kenneth Erlang/OTP, Ericsson
On Sat, Nov 15, 2008 at 7:54 PM, damien morton <dmo...@bitfurnace.com> 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?
Richard O'Keefe
On 17 Nov 2008, at 1:44 pm, Håkan Stenholm wrote:
> Conditionals that have more than 2 branches where none of them
> branch on
> patterns - e.g. something like the to_upper code below:
>
> to_upper_char(C) when is_integer(C) ->
> if
> $a =< C, C =< $z -> C - 32;
> 16#E0 =< C, C =< 16#F6 -> C - 32;
> 16#F8 =< C, C =< 16#FE -> C - 32;
> true -> C
> end.
If this is supposed to convert ISO Latin 1 characters
to upper case, it's wrong. (In at least two different
ways, both of which are left as an exercise for the
reader.) Code for such purposes simply shouldn't be
written by hand these days, but should be generated by
some sort of script from the (relevant portion of the)
Unicode data base. As such, whether it's written using
'case', 'if', or embedded Intercal should be of no interest.
> case .... of
> _ when ... -> ...
> _ when ... -> ...
> _ when ... -> ...
> ...
> end
Did I write up a proposal for
case ...
of ... when ... -> ...
; when ... -> ...
; ...
; ... when ... -> ...
; when ... -> ...
; ...
; .......
end
or did I just stick it into my radically incomplete micro-Erlang?
damien morton
> let's throw in my 5 cents ...
... $9.95
> We need an infrastructure. The genius of the Wikipedia is that it is
> an organisational form that allows a lot of people to contribute by
> doing a little. Correcting a spelling mistake, asking a question,
> replying to a question has enormous power when done by hundreds or
> thousands of people.
>
> /Joe Armstrong
Google Code provides for line-by-line and revision-by-revision reviews:
http://code.google.com/p/support/wiki/CodeReviews
Johnny Billquist
> On 17 Nov 2008, at 1:44 pm, Håkan Stenholm wrote:
>> Conditionals that have more than 2 branches where none of them
>> branch on
>> patterns - e.g. something like the to_upper code below:
>>
>> to_upper_char(C) when is_integer(C) ->
>> if
>> $a =< C, C =< $z -> C - 32;
>> 16#E0 =< C, C =< 16#F6 -> C - 32;
>> 16#F8 =< C, C =< 16#FE -> C - 32;
>> true -> C
>> end.
>
> If this is supposed to convert ISO Latin 1 characters
> to upper case, it's wrong. (In at least two different
> ways, both of which are left as an exercise for the
> reader.) Code for such purposes simply shouldn't be
> written by hand these days, but should be generated by
> some sort of script from the (relevant portion of the)
> Unicode data base. As such, whether it's written using
> 'case', 'if', or embedded Intercal should be of no interest.
??? That's a perfectly correct translation from lowercase to uppercase
for Latin-1.
Unicode is something else.
Or is there just some bug in the code as such that I fail to see?
Johnny
Hasan Veldstra
"straße" - German for "street" - can be encoded in ISO Latin 1, but
both your code and the one in the standard string module will fail to
convert it to upper-case properly.
Thomas Lindgren
--- On Wed, 11/19/08, Robert Virding <rvir...@gmail.com> wrote:
> Thomas Lindgren mentioned one reason why the APIs look like
> they do, no
> vetting. Another early reason is that we were concentrating
> on some aspects
> of the language, and implementing it, and often we just
> need a library so we
> hacked one together. And we still have them hanging around.
> An unfortunate
> and slightly depressing prerequisite to these reasons is
> that some didn't
> have the inclination or time to make a good API.
Maybe Erlang/OTP needs, dare I say it, a chief architect? Or at least someone with (sine qua non) good taste in APIs, a strong conviction, and the raw hacking power to rewrite all submitted code to follow The One True Way :-)
Best,
Thomas
Johnny Billquist
Well, Latin-1 don't have an uppercase version of ß, so that letter can't
be converted, if you want to stay in Latin-1. The rest will do just fine.
So, within the limitations of Latin-1, the function works fine, as far
as I can tell.
Johnny
Valentin Micic
> be converted
What is the uppercase for "ß"?
V.
Bengt Kleberg
http://www.alvestrand.no/pipermail/idna-update/2008-March/001281.html:
the facts of current German orthography are that the
uppercase of ß is "SS"
I stopped looking when I found a quote that supports my own opinion.
bengt
Those were the days...
EPO guidelines 1978: "If the contribution to the known art resides
solely in a computer program then the subject matter is not
patentable in whatever manner it may be presented in the claims."
Richard Carlsson
> the facts of current German orthography are that the
> uppercase of ß is "SS"
Quite. The lesson should be that even "within the limitations of
Latin-1", the idea that you can do case conversion on single
code points is wrong. It is an operation that should be applied
to strings, not individual characters.
/Richard
mats cronqvist
> Did I write up a proposal for
> case ...
> of ... when ... -> ...
> ; when ... -> ...
> ; ...
> ; ... when ... -> ...
> ; when ... -> ...
> ; ...
> ; .......
> end
> or did I just stick it into my radically incomplete micro-Erlang?
i've seen it, and it pleased me greatly.
mats
Johnny Billquist
> Bengt Kleberg wrote:
>> the facts of current German orthography are that the
>> uppercase of ß is "SS"
>
> Quite. The lesson should be that even "within the limitations of
> Latin-1", the idea that you can do case conversion on single
> code points is wrong. It is an operation that should be applied
> to strings, not individual characters.
And I don't agree. You are mixing semantics with syntax, in my mind
(syntax is probably not the right word here, but I'm no typographer so I
don't know the correct term, but I hope you understand what I mean).
There is no uppercase version of ß, so it can't be converted to uppercase.
The fact that you write SS instead of ß, when you want it in uppercase
don't mean that it's the same letter, just that it has the same meaning.
Conversion of a string to uppercase can be regarded in two ways. Either
you replace each character with it's uppercase version, and characters
that don't have an uppercase version you leave be.
Or you can try to convert the string as such to an uppercase version,
where some letters might need to be replaced by sequences of other
characters.
I personally usually are satisfied with the previous, but I guess that's
anyones choice.
And I also believe that this is one of the more serious flaws of
Unicode. It mixes semantics with syntax. So you have, for instance
several A-ring characters, for use in different type of contexts, but
that is all artificial and unfortunate.
It's like in the old days, when you had several different minus signs on
punched cards, for different uses. Hmm, looking at Unicode, I can see
that they have reintroduced this ambiguity. You have hyphen-minus
(U+002D), hyphen (U+2010) and minus (U+2212) and you also have a number
of different dashes.
Try to figure out which one you want when you are writing.
(According to one myth this "problem" actually caused the Mariner 1 to
fail and self destruct, since the poor Fortran programmer hade used a
hyphen instead of a minus for a constant. Not sure if it's true or not,
and the web don't give a sure answer.)
(Oh, and the A-ring problem is that there is a unit called Ångström,
which uses the symbol Å. However, in Swedish, A-ring (Å) is a normal,
plain letter, and the guy Ångström was a Swede, and the unit was named
after him, with the first letter of his last name as the unit, but with
Unicode we now need to know if we're writing the letter Å, or the unit
Å, which is a different codepoint, even though it actually is the same
letter.
There are more examples like this, where Unicode mess things up because
it mix the visual impression of a character with semantic meaning of the
character.)
And when I learned German in school many years ago, I was taught that ß
was more or less the equivalent of sz. :-)
Johnny
Kevin Scaldeferri
On Nov 19, 2008, at 6:04 AM, Johnny Billquist wrote:
> Richard Carlsson wrote:
>> Bengt Kleberg wrote:
>>> the facts of current German orthography are that the
>>> uppercase of ß is "SS"
>>
>> Quite. The lesson should be that even "within the limitations of
>> Latin-1", the idea that you can do case conversion on single
>> code points is wrong. It is an operation that should be applied
>> to strings, not individual characters.
>
> And I don't agree. You are mixing semantics with syntax, in my mind
> (syntax is probably not the right word here, but I'm no typographer
> so I
> don't know the correct term, but I hope you understand what I mean).
> There is no uppercase version of ß, so it can't be converted to
> uppercase.
> The fact that you write SS instead of ß, when you want it in uppercase
> don't mean that it's the same letter, just that it has the same
> meaning.
At least in the context of the German language, ß is nothing more than
a shorthand for ss. Similarly ö is shorthand for oe, and so on. If
your string functions are not aware of this, then they are wrong. Of
course, this exposes that the situation is quite complicated and
subtle. Quite possibly these equivalences do not hold in other
languages. This means that a function like "to_upper" operating on
Latin-1 that isn't locale-aware is a wrong interface.
> (Oh, and the A-ring problem is that there is a unit called Ångström,
> which uses the symbol Å. However, in Swedish, A-ring (Å) is a normal,
> plain letter, and the guy Ångström was a Swede, and the unit was named
> after him, with the first letter of his last name as the unit, but
> with
> Unicode we now need to know if we're writing the letter Å, or the unit
> Å, which is a different codepoint, even though it actually is the same
> letter...)
Well this is really just another example. If you lowercase the
Swedish letter Å you should get å. However, it would be wrong to do
the same for the symbol for the unit.
>
> There are more examples like this, where Unicode mess things up
> because
> it mix the visual impression of a character with semantic meaning of
> the
> character.)
No, it doesn't do this at all. Unicode defines characters. It does
not define glyphs. It is understood that the mapping of characters to
glyphs is many-to-many.
>
>
> And when I learned German in school many years ago, I was taught
> that ß
> was more or less the equivalent of sz. :-)
The _pronunciation_ is somewhat like that. But the character is
identical to ss.
-kevin
Toby Thain
How could a German reader *possibly* be satisfied with the incorrect
result of the over-simple-minded method!!
>
> And I also believe that this is one of the more serious flaws of
> Unicode. It mixes semantics with syntax. So you have, for instance
> several A-ring characters, for use in different type of contexts, but
> that is all artificial and unfortunate.
> It's like in the old days, when you had several different minus
> signs on
> punched cards, for different uses. Hmm, looking at Unicode, I can see
> that they have reintroduced this ambiguity. You have hyphen-minus
> (U+002D), hyphen (U+2010) and minus (U+2212) and you also have a
> number
> of different dashes.
> Try to figure out which one you want when you are writing.
Nothing substitutes for a typographic education if you wish to use a
typographic palette.
> (According to one myth this "problem" actually caused the Mariner 1 to
> fail and self destruct, since the poor Fortran programmer hade used a
> hyphen instead of a minus for a constant. Not sure if it's true or
> not,
> and the web don't give a sure answer.)
Unlikely to be true, but a failure of testing, surely.
>
> (Oh, and the A-ring problem is that there is a unit called Ångström,
> which uses the symbol Å. However, in Swedish, A-ring (Å) is a normal,
> plain letter, and the guy Ångström was a Swede, and the unit was named
> after him, with the first letter of his last name as the unit, but
> with
> Unicode we now need to know if we're writing the letter Å, or the unit
> Å, which is a different codepoint, even though it actually is the same
> letter.
> There are more examples like this,
Hundreds more (for example, Hebrew or Fraktur letters as mathematical
symbols). And there may be an associated rationale.
> where Unicode mess things up because
> it mix the visual impression of a character with semantic meaning
> of the
> character.)
>
> And when I learned German in school many years ago, I was taught
> that ß
> was more or less the equivalent of sz. :-)
Is that relevant? The orthographic rule is what it is.
--Toby
Valentin Micic
meaning and that "ß" just represents a short way of writing "ss".
As for pronunciation, I think that single s is indeed pronounced "sz", thus
Suzuki in German sound quite contrary to what one would expect. I might be
wrong, but scharfes s is used to eliminate "z" sound in "s", hence Strasse,
I mean -- Straße.
V.
Julian Bäume
On Wednesday 19 November 2008 17:08:02 Valentin Micic wrote:
> I was under impression that one may write a lowercase ss with the same
> meaning and that "ß" just represents a short way of writing "ss".
No, in fact you change the pronunciation of the vowel right before "ß" or
"ss". If you write "ss", the vowel before is spoken much shorter than with "ß"
following.
> As for pronunciation, I think that single s is indeed pronounced "sz", thus
> Suzuki in German sound quite contrary to what one would expect. I might be
> wrong, but scharfes s is used to eliminate "z" sound in "s", hence Strasse,
> I mean -- Straße.
Pronunciation of the "ss" or "ß" in words is the same. One example here is:
"muss" and "Muß". The difference in pronunciation is just that you speak a
short "u" in the first and a long one in the second case.
Concerning the uppercase version of "ß": There is quite no need for that. The
discussion about the need of an uppercase "ß" is much older than computers....
Since April this year there is a Unicode character that represents the capital
ß.
This article in the English wikipedia gives a short overview about this topic:
http://en.wikipedia.org/wiki/Capital_ß
Some time ago I read a very interesting discussion in a German typography
forum about how this letter should look like.
http://www.typografie.info/typoforum/viewtopic.php?f=2&t=300&st=0&sk=t&sd=a
I guess, it was this one, but I'm not sure.
just my 2ct..
Julian
Robert Raschke
to the language used when writing the text. It does not translate well
between languages in general. Things are complicated by the fact that
there are so many Latin influenced languages that make it appear like
there are common operations that you can carry out.
The ß letter in german actually evolved out of a ligature of fraktur s
(kinda looks like an upside down l) and z (looks a bit like a g with
its left hand side chopped off). So, in the language you have the need
for several types of the "ess" sound, soft (s) and hard (sz). Since
this latter one lended itself to getting squashed together a bit
during printing, you end up with a nice looking "letter" (similar in
spirit to the fi ligature, for example). The fraktur printing alphabet
got replaced by the latin based one and the ligature got replace by
that strange thing that looks like a beta. The old handwritten german
was completely bizarre (I've forgotten the name of it, but it looked a
lot like the sharp end of a saw).
On top of all that, there was recently (last ten years ago or so) the
decision to revise some of the writing standards of German,
essentially making it completely valid to write ss instead of ß, oe
instead of ö, etc.
It can be funny how written language can evolve. In Dutch there used
to be a letter y with two dots (umlaut) on it, nowadays they write
that as ij.
Robby
David Mercer
The first is for typographic reasons. I don't think a programmatic approach
is ever going to satisfy every possible case automatically.
The other, however, is normalization, probably for comparison
purposes––i.e., case-insensitive comparisons. In that case, being correct
typographically isn't as important as consistency in how you represent a
character. Ignoring the Unicode normalization approaches (regarding accents
and combining characters, etc.), a simplistic up-casing algorithm may be all
that is needed. Someone might object to up-casing the "p" in "pH", for
example, but this is not for typographical purposes, but simply for
normalization purposes. With that in mind, I would imagine that that German
beta-looking character probably should be normalized to "SS", but bear in
mind that this is coming from someone who doesn't know German and probably
would have pronounced "straße" STRAYB, so I won't be the one to write that
canonical code. :-)
Please let me know if there are use cases I am missing and which enhance
this discussion.
Cheers,
David
Jouni Rynö
On Nov 19, 2008, at 16:04 , Johnny Billquist wrote:
>> Bengt Kleberg wrote:
>>> the facts of current German orthography are that the
>>> uppercase of ß is "SS"
>>
>>
Keep looking, there is, since spring 2008, capital ß ..., typography
is still? open, see
http://en.wikipedia.org/wiki/Capital_ß
Jouni
damien morton
>> We need an infrastructure. The genius of the Wikipedia is that it is
>> an organisational form that allows a lot of people to contribute by
>> doing a little. Correcting a spelling mistake, asking a question,
>> replying to a question has enormous power when done by hundreds or
>> thousands of people.
>
> alternative to a web-based code review tool. The forking and pulling
> workflow supports code review as-is, albeit not explicitly (cf.
> http://shifteleven.com/articles/2008/05/17/code-reviews-inherit-in-git).
> Switching to an e-mail client, or some code review application is too
> much work, particularly for smaller contributions.
git is probably the most user unfriendly SCM tool I have come across.
Is the SVN/CVS plus web-based browsing and code review using google
code not acceptable?
Tim Fletcher
> (in PDF, HTML, ...) - think "book quality"
What tools are used to generate the Erlang PDF manuals? Would they be
suitable?
> We need an infrastructure. The genius of the Wikipedia is that it is
> an organisational form that allows a lot of people to contribute by
> doing a little. Correcting a spelling mistake, asking a question,
> replying to a question has enormous power when done by hundreds or
> thousands of people.
Agreed. I think using a distributed SCM such as git would be a good
alternative to a web-based code review tool. The forking and pulling
workflow supports code review as-is, albeit not explicitly (cf.
http://shifteleven.com/articles/2008/05/17/code-reviews-inherit-in-git).
Switching to an e-mail client, or some code review application is too
much work, particularly for smaller contributions.
_______________________________________________
Håkan Stenholm
>
> On 17 Nov 2008, at 1:44 pm, Håkan Stenholm wrote:
>> Conditionals that have more than 2 branches where none of them branch on
>> patterns - e.g. something like the to_upper code below:
>>
>> to_upper_char(C) when is_integer(C) ->
>> if
>> $a =< C, C =< $z -> C - 32;
>> 16#E0 =< C, C =< 16#F6 -> C - 32;
>> 16#F8 =< C, C =< 16#FE -> C - 32;
>> true -> C
>> end.
>
> If this is supposed to convert ISO Latin 1 characters
> to upper case, it's wrong. (In at least two different
> ways, both of which are left as an exercise for the
> reader.)
taken from string.erl in R12B-5.
to_upper_char(C) when is_integer(C), $a =< C, C =< $z ->
C - 32;
to_upper_char(C) when is_integer(C), 16#E0 =< C, C =< 16#F6 ->
C - 32;
to_upper_char(C) when is_integer(C), 16#F8 =< C, C =< 16#FE ->
C - 32;
to_upper_char(C) ->
C.
I choose this function because it was a simple example of where a 'if'
is nicer than a 'case' or a guard, not because of any merit (or lack
thereof) of the purpose of the above code itself. Maybe we should get
back to discussing Erlang 3000 in this thread? e.g. could 'if' be
replaced by another construct ... , rather than discussing the nastiness
of unicode and various other text encodings.
Joe Armstrong
questions and try to define some kind of "best practice"?
What is best practice for testing and and documenting code? Should modules
contain test cases - or should these be in separate files?
Should modules contain APIs or should these be in separate interface documents?
What meta data should a module have?
What is the best way to use:
1) edoc
2) type signatures
3) meta data
4) unit testing
5) cross ref
6) type analysis
Note I say "best way" - not how to use these things ...
and so on ...
I have a feeling that the toolset is important here. There is no
incentive to write
inline tests in the code if this is not backed up with a good
production system. There is
no incentive to write in-line documentation if I can get better
results with off-line LaTeX.
I think we should try to define a minimal set of standards that define
best practice - then make the tools to support the codeing style we adopt.
Personally I don't like stuffing everything into one file - I'd like to see
X.erl (the code)
X.sig (the interface type signature and terse documentation)
X.doc (verbose - high quality documentation)
X.test (test cases)
With tools to produce html, pdf, cross listings, indices, reports, ... etc.
Also organisation of code is interesting - when projects are small I
put all code
in the same directory - as they grow the code gets split into
directories - as they get
huge no amount of directory organisation helps - well index'ed meta
data is the only thing
that helps. All modules should probably have a GUID with some kind of
tracking software
that can track all derivatives of a module.
We can start with edoc and docbuilder and ... and see how things go ...
/Joe
Johnny Billquist
Can people now agree that it is not correct to just replace a ß with ss,
and a correct capitalization of ß is not possible in Latin-1?
Just as I would say it would not be correct to replace ö with oe, even
though ö is sorted as oe in German. (Ö is a separate letter with it's
own correlation in Swedish, by the way.)
Johnny
Julian Bäume skrev:
Robert Virding
Maybe Erlang/OTP needs, dare I say it, a chief architect? Or at least someone with (sine qua non) good taste in APIs, a strong conviction, and the raw hacking power to rewrite all submitted code to follow The One True Way :-)
Yes, something like that. Although he/she shouldn't have to do all the hacking, just enforce that the submitted code follow The One True Way.
Robert
Dale Harvey
non otp libraries, the lack of a central release repository is a hinderance,
but a single repository is unlikely to breakthrough very soon. I think
a good alternative would be to allow the code / project to exist anywhere,
but have a central place to find and document these libraries.
I have been planning to set up a public fork to the erlang
docs once they were fully released. I originally planned it to sort out
simple usability apects, like a function overview at the top of a
module page, an as you type filter of libraries /
modules. I also wanted feedback / comment options as
with php / flex docs,
(http://se2.php.net/manual/en/function.socket-set-option.php)
But it sounds like setting up a global documentation repository
would be a perfect extension.
an interface can be built to standard repositories (faxien / github etc)
that could be used to pull in documentation from to be included
alongside the standard/otp docs, categorised (alpha / beta / stable) etc.
users would then have a central source for finding user libraries,
along side searching the otp documentation, search within versions,
compare functionality, comment on libraries quirky features etc.
I can start building the integration stuff now, but the site wont really be useful
until the rest of the doc builder ala I can build everything up to
http://www.erlang.org/doc/ is released, hopefully thats the stuff planned for R13