Erlang standard library quirks
Wed Feb 8 18:45:44 CET 2006
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.
> (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
The paper in Software, Practice and Experience describing the string
storage for Icon was much more readable and understandable.
More information about the erlang-questions