[erlang-bugs] Bug in gb_trees ? Integer key not found.

[Matthias Lang]

Hi,

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)

Matt