Erlang standard library quirks

[Robert Virding]

Matthias Lang skrev:
> James Hague writes:
> 
>  > What standard library quirks bug you?
> 
> Two that spring to mind:
> 
>   - 'string' and 'list' use conflicting argument order conventions.
> 
>     In the string module, all functions which operate on a string
>     take the string as the _first_ argument.
> 
>     In the list module, the list is _last_ more often than not.
> 
>     Example: string:chr versus lists:member
> 
>     Not much which can be done about this, I think we're stuck with it.

String uses the convention that the thing you are working on comes 
first. So does part of lists. While those functions in lists which take 
functional arguments have been influenced by functional languages where 
the thing comes last so you can more easily build partial evaluations. Yeah!

The standard libraries are full of inconsistencies, not just argument 
order conventions, there are many, too many, naming conventions, both 
for functions and modules. Two reasons are different influences and that 
we just didn't worry about in the beginning. You could always change it 
later. However, then users started whining and complaining so we 
couldn't set it right. :-)

>   - The general vagueness about the speed/size properties of dict, 
>     sets, gb_trees and other data structures. gb_trees (1), which
>     is one of the 'less vague' ones says
> 
>       Behaviour is logaritmic [sic] (as it should be).
> 
>     An alternative which is almost as terse, but more informative:
> 
>       Insertion, deletion and lookup are O(log N), amortised.
> 
>     dict is worse, with just a snooty
> 
>        The representation of a dictionary is not defined.
> 
>     it may as well say "don't you worry about that". Turns out
>     it's a hash (2).

(Snooty reply) One reason for having an abstract data type like dict IS 
to hide the internal representation so that users don't go in and fiddle 
with things they should best leave alone.

> Matthias    
> 
> (1): The original (?) paper about gb_trees is pleasantly lucid, a
>      pleasure to read: http://user.it.uu.se/~arnea/abs/gb.html

> (2): Read the source, or
> 
>        http://thread.gmane.org/gmane.comp.lang.erlang.general/12385
>        http://www.cs.cmu.edu/afs/cs.cmu.edu/user/christos/www/courses/826-resources/PAPERS+BOOK/linear-hashing.PDF

The paper in Software, Practice and Experience describing the string 
storage for Icon was much more readable and understandable.