[erlang-patches] [patch] binary to/from integer

[Loïc Hoguin]

On 01/11/2013 03:01 PM, Björn-Egil Dahlberg wrote:
> On 2013-01-11 09:33, Bengt Kleberg wrote:
>> Greetings,
>>
>> FWIW I would like to not autoimport any more functions. The existing
>> ones are confusing enough when reading up on new code.
> I agree.
>
> Hence why I would like to put new BIF functions in other modules.
>
> The only argument for having a binary_to_integer and friend
> auto-imported is by friendship to list_to_integer and such functions.
> Since those functions are auto-imported these ones should be too.
>
> The argument is mute if we change the module I think.

By friendship? That's a weird way to say it.

This is *consistency*.

There are a number of base types in Erlang, including atom(), integer(), 
float(), list() and binary(). (list() here is generally thought to be 
string() when it is converted from/to other types, integer_to_list/1 
really isn't the best name for it).

One would expect conversion from one type to another to be easy to use, 
efficient and also fast. One would also expect some cases to be edge 
cases, for example atom to integer, so these do not need a direct 
conversion mechanism. A developer surely understands that if he does 
something unusual he'll have to go through more hoops to get his job done.

Let's take a look at these types and the current state of the API.

atom()
   to_integer: edge case
   to_float: edge case
   to_list: available, but means to_string
   to_binary: available, encoding is required as a 2nd argument

When we get UTF-8 atoms, people will start expecting an atom_to_binary/1 
that aliases atom_to_binary/2 with utf8 as default argument.

integer()
   to_atom: edge case
   to_float: edge case
   to_list: available, but means to_string, can also specify base
   to_binary: list_to_binary(integer_to_list(I)), inconvenient

float()
   to_atom: edge case
   to_float: edge case
   to_list: available, but means to_string
   to_binary: list_to_binary(float_to_list(F)), inconvenient

Of note is that floats are rarely used in Erlang, so perhaps 
float_to_binary/1 isn't really needed.

list()
   to_atom: available, also in a safe form
   to_float: yep
   to_integer: yep, also with base
   to_binary: yep

You can convert everything to list, but in all cases it means string().

binary()
   to_atom: available, need to specify encoding, safe form available
   to_float: list_to_float(binary_to_list(B)), inconvenient
   to_integer: list_to_integer(binary_to_list(B)), inconvenient
   to_list: available, but means to_string

This shows a number of issues and shortcomings.

The biggest one is that when you write 'list' when converting from one 
type to another, you always mean 'string'. I suppose this is historical, 
but it's part of what makes string handling in Erlang so difficult.

Another is that today, I need to think when converting binary strings to 
integer, because you write it:

   intermediate_to_final(initial_to_intermediate(Value))

So everytime I perform a double conversion I have high chances to 
introduce a bug and waste time.

Tomorrow, I could be using these functions:

  *  list_to_atom/1
  *  list_to_integer/1
  *  list_to_float/1
  *  binary:from_list/1

One would expect list_to_binary/1 here. Because that would be consistent 
(but semantically not exact as you convert a string(), not any list()).

If auto-imported BIFs are a problem, perhaps a slow move to a single BIF 
for example to(ToType, Value) could be beneficial.

I'd much rather write to(binary, 123) than any of the alternatives or 
current proposals including integer_to_binary. It loses the feature that 
integer_to_binary would check that the value is an integer first, but I 
don't think it's often counted on in people's code so that could be done 
separately for the rare cases where it's actually needed.

It would also fix the consistency issues, would allow fixing the 
semantics of list actually meaning string, and a to/3 version could take 
options as a third argument for the cases where encoding or checking for 
atom existence are necessary. It would also be easier to add another 
type later on.

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu