Why does Erlang provide built-in ordering (sorting) of the basic data types

erlangsorting

In Erlang, an ordering of the built-in basic data types has been established:

number < atom < reference < fun < port < pid < tuple < list < bit string

This means that sorting a list with a variety of different data types is possible. ([1, 2, 'foo', 42, {3}, 1] becomes [1, 1, 2, 42, {3}, 'foo']).

However, it seems very counter-intuitive to me to have this behaviour defined: Usually, when dealing with an enumerable that has multiple different types of data, I'd use a custom function so the order is exactly as I want.

I would expect a number not be able to be compared (in order) with i.e. strings. In many other programming languages this indeed is true and will throw an error.

Why does Erlang provide this ordering of the basic data types?

Best Answer

Quoting Joe Armstrong (emphasis mine):

The original reason was that there should be a defined total order over all terms (why? - so that we could write generic sorting algorithms that could order any terms).

The actual order was based on the idea of "complexity" an integer is "simpler" than an atom. a tuple is simpler than a list and so on..

There was no real definition of "simpler" it was more or less the size that an object took in memory (by which measure [], should have been smallest, but is not :-).

The actual order is not important - but that a total ordering is well defined is important.

/Joe

Related Topic