[erlang-bugs] Bug in gb_trees ? Integer key not found.
Fri May 13 08:27:54 CEST 2011
I think it is worth mentioning the attempt made by Ricard C. "Erlang
standard library packages". The comments say:
Basically following Jonas B. et al., "proposal 15"
So some work has been done on this subject.
On Thu, 2011-05-12 at 18:36 +0200, Matthias Lang wrote:
> sorry about the missing threading headers.
> Eric wrote:
> > In addition to this, there is 'from_list' functions in queue, ordsets,
> > array, orddict, dict, sets and gb_sets modules, but not in gb_trees ...
> > Why not :>) ?
> Completely agree with your observation that more consistency would be
> nice. My 'favourite' example is deciding the function and argument
> order when finding out if something's in a structure:
> lists:member(Element, Structure)
> ets:member(Structure, Element)
> string:chr(Structure, Element)
> [ord]dict:is_key(Element, Structure)
> sets:is_element(Element, Structure)
> gb_trees:is_defined(Element, Structure)
> None of the those present when this happened have chosen to comment on
> the 'why', here are my guesses:
> Why did it start? A "just do it!" spirit when Erlang was born, along with
> different people having different ideas about how to do things.
> Why is it still that way? Backwards compatibility has always been a
> high priority in Erlang because it's been used in real products almost
> from the start. Cleaning up has usually taken a back seat. But changes
> like adding 'from_list' to gb_trees should be uncontroversial.
> Aside: just spotted a bug in the 'sets' manpage. It says:
> | This module provides exactly the same interface as the module
> | ordsets but with a defined representation.
> The bit about "defined representation" looks like a cut-and-paste
> error from ordsets. (I looked at R14B0, erlang.org is down for me)
> erlang-bugs mailing list
More information about the erlang-bugs