Erlang standard library quirks

[Richard Carlsson]

Bengt Kleberg wrote:
> richard c had a nice collection of better (imho) alternatives to the 
> standard library functions. i have a set i got many years ago, but
> does anybody know where to find them today?

Most of what I did was organize the existing built-ins into the
package system; e.g., erlang:exit/1 has an alias erl.lang:exit/1,
lists:reverse/2 can be found as erl.lang.list:reverse/2, and so on.
This was based on an old plan from the Standard Erlang Specification
project, to rearrange the existing ad-hoc collection of bifs. When
I got the package system working, I thought it was a good opportunity
to use it to implement the bif-reorganizing plan, but I didn't get
much enthusiasm and feedback (except from Bengt Kleberg), so it's
simply been left hanging for a long time now.

For the curious, the list of built-ins that have package aliases
can be found in the file erts/emulator/beam/bif.tab. Since few people
know about them at all, the names are not cast in stone yet.

There is also a corresponding set of source files for these modules,
such as erl.lang, erl.lang.list, erl.lang.term, erl.util.date, etc.
I could make this available again if there is interest out there in
making this an accepted set of standard libraries. (Currently they
only contain a little bit of code that adds new functionality - most
of it is just aliases and wrappers.)

One thing that did not exist previously, but which I had in mind when
I started working on these new libraries, was the try-catch construct.
It was my intention that the new library functions should _not_ use
the {ok, Value}/{error, Reason} return convention (except in special
cases where the likelihood of error is on par with that of success).
Today, the try construct is actually present and working, so maybe the
time has come to get this project rolling again.

It's not something that I'd want to do all on my own, though.
Volounteers would be needed, both to port old library code and/or
write wrapper functions, test things, argue about module and function
names, and so on. The code could be put on sourceforge or similar.
There would necessarily be a fairly long period of testing before
it could be declared stable, so you couldn't start relying on its
functions for serious work immediately, but it's a start.

Any takers?

	/Richard