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

[Björn-Egil Dahlberg]

On 2013-01-11 16:44, Loïc Hoguin wrote:
> 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*.

Nitpicking - I thought consistency was implied since it is the sole 
reason for this whole thread.

=)

The thread began, and to be clear I'm paraphrasing here, - "I don't 
really have time to do this but .. "

And I do agree with most of what you say below, if not all.

Weird prolog string legacy and type conversions thereof. But that's the 
thing right. In the erlang module we talk about type conversions and we 
don't have a string type. Hence integer_to_list and float_to_list. By 
*consistency* it should be integer_to_binary and binary_to_integer since 
it is types we talk about in those functions.

I'm feeling that headache again.

Perhaps gradually moving conversions to other modules is the way forward.
Perhaps a string datatype is necessary.

Neither will happen right now.

// Björn-Egil
> 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.
>