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

Loïc Hoguin essen@REDACTED
Thu Jan 10 23:05:30 CET 2013 

binary:integer_to_string/1 is hardly intuitive. Especially if you write 
it like this:

Module = binary,
%% ...
Module:integer_to_string(123)

Do you get a binary() or a string()?

If you create a function type1_to_type2 it's much better if type1 and 
type2 correspond to actual types.

Wherever you place it I don't think it should be named anything other 
than integer_to_binary. However it should be autoimported, because 
writing integer_to_binary first and then remembering the function 
doesn't exist is what many of us do regularly. We already have the 
reflex, we only miss the call to be available.

On 01/10/2013 08:31 PM, Serge Aleynikov wrote:
> Thanks for the explanation!  The API naming is a headache indeed.
>
> It does make sense to define these functions in the binary module.
> Though while binary:string_to_integer/1 is intuitive, I think
> binary:integer_to_string/1 would be a more intuitive name than
> binary:string_from_integer/1 (this also would be more consistent with
> binary:{bin,list}_to_{list,bin}.
>
> On 1/10/2013 1:50 PM, Björn-Egil Dahlberg wrote:
>> On 2013-01-10 18:55, Serge Aleynikov wrote:
>>> I was under impression that Lucas would take care of modifications he
>>> proposed in the thread you quoted.  Meanwhile I'll see if I can find
>>> time to do this.
>> I think the key words were "if it gets prioritized"  =)
>> Granted, we could be more clear on intention. I think in this case we
>> supposedly had time which drastically changed at some point ..
>>
>>>
>>> Do you already have an implementation of binary <-> integer?  If not,
>>> maybe I could look at that one as well when I poke around the BIFs,
>>> since this is also something very commonly needed.
>> Right, what I did was to take the list conversions to integer and made
>> it binary comprehensible.
>>
>> That was the easy bit.
>>
>> However,
>> Now I have
>>   * erlang:binary_to_integer/1 and
>>   * erlang:integer_to_binary/1
>> which seems fine. The compiler will auto-import them as well.
>>
>> After I did that I began to reconsider this choice. Perhaps it should be
>>
>> * binary:to_integer/1 and binary:from_integer/1 instead? Or,
>> * binary:string_from_integer/1 and binary:string_to_integer/1,
>> emphasizing that this is a textual representation of integer in binary
>> format. Then I got a headache.
>>
>> The arguments for the first one (current) is:
>> * list_to_integer has same type of ideas, same type of behavior. Avoids
>> confusion.
>> The arguments against the first one,
>> * Clutters the erlang module with yet more BIF's
>> * We already have a binary module, let's use it!
>> * And finally: avoid confusion! Does erlang:integer_to_binary(102341)
>> mean <<0,1,143,197>> or <<"102341">> ?
>>
>> I'm leaning towards the latter.
>>
>> Also, I didn't implement base conversion, so that needs doing. I think
>> the list conversion is done in Erlang which seems backwards.
>>
>> Anyways, the current implementation is at:
>> https://github.com/psyeugenic/otp/commits/egil/r16/binary_to_integer
>>
>> But the real work is taking a position on the API and consider the
>> different ramifications. I still have that headache ..
>>
>> Yet another also, perhaps this implementation isn't the way to go. From
>> what I remember erlang:binary_to_integer didn't have the speedup I first
>> envisioned. Ofc, it was faster than doing
>> binary_to_list(list_to_integer(X)) but binary_to_integer was on par with
>> this list_to_integer .. which seemed a bit off.
>>
>> I want to refrain from using strtol directly (I think that
>> implementation is similar anyways and we still need to handle bignums).
>>
>> I think I want to change the current implementation to taking the base
>> as argument to the BIF and perhaps using arity one function as an erlang
>> wrapper. (And doing the same for list_to_integer). The arguments against
>> that is, surely the arity one functions is far more used and it should
>> be slightly faster to that call directly.
>>
>> // Björn-Egil
>>
>>>
>>> On 1/10/2013 12:41 PM, Björn-Egil Dahlberg wrote:
>>>> On 2013-01-10 18:08, Serge Aleynikov wrote:
>>>>> Not quite - in two days my "new float_to_list/2" patch is celebrating
>>>>> its 2 year anniversary sitting in the awaiting mode.  ;-)
>>>> Nice =o
>>>> However, it is not really as you imply. A simple patch that has been
>>>> ignored for two years =)
>>>>
>>>> I checked in Monitor/OTP:
>>>> * sal/float_to_list_2
>>>> * status: unassigned
>>>> * location: limbo (not present in any active backlog)
>>>> * notes: waiting for response from author (noted by Lukas)
>>>>
>>>> Lukas is currently on a mountain somewhere in south america so I can't
>>>> really ask him about it.
>>>>
>>>> As I recall, your patch had some controversy about precision?
>>>>
>>>> And the last mail conversation mention something about modifications
>>>> needed and if we were to do it we had to prioritize it along with
>>>> already planned work. Needless to say, it hasn't been prioritized.
>>>>
>>>> http://erlang.org/pipermail/erlang-patches/2012-August/002980.html
>>>>
>>>> Personally trying to find time to get binary (text) <-> integer
>>>> conversions into the backlog.
>>>>
>>>> Being realistic, neither your float conversion nor mine will make it to
>>>> r16. *sadface*
>>>>
>>>>
>>>> // Björn-Egil
>>>>
>>>>> On 1/10/2013 10:51 AM, Max Lapshin wrote:
>>>>>> Serge, you seems to be a fast way to pull patch into upstream =)
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov <serge@REDACTED
>>>>>> <mailto:serge@REDACTED>> wrote:
>>>>>>
>>>>>>        That was the fastest acceptance of a patch I ever submitted.
>>>>>> ;-)
>>>>>>
>>>>>>        On 1/10/2013 10:03 AM, Fredrik wrote:
>>>>>>        > Hello Serge,
>>>>>>        > Your patch is now in the 'master-pu' branch.
>>>>>>        > Thanks for your contribution!
>>>>>>        >
>>>>>>        > BR Fredrik Gustafsson
>>>>>>        > Erlang OTP Team
>>>>>>        > On 01/10/2013 03:31 PM, Serge Aleynikov wrote:
>>>>>>        >> Added an application:get_env/3 function variant that
>>>>>> provides a
>>>>>>        default
>>>>>>        >> value for a configuration parameter:
>>>>>>        >>
>>>>>>        >>     application:get_env(App, Key, Default) ->  Value.
>>>>>>        >>
>>>>>>        >> git fetch git://github.com/saleyn/otp.git
>>>>>>        <http://github.com/saleyn/otp.git> get_env
>>>>>>        >>
>>>>>>        >> https://github.com/saleyn/otp/compare/erlang:master...get_env
>>>>>>        >>
>>>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.patch
>>>>>>        >> _______________________________________________
>>>>>>        >> erlang-patches mailing list
>>>>>>        >> erlang-patches@REDACTED <mailto:erlang-patches@REDACTED>
>>>>>>        >> http://erlang.org/mailman/listinfo/erlang-patches
>>>>>>        >
>>>>>>        _______________________________________________
>>>>>>        erlang-patches mailing list
>>>>>>        erlang-patches@REDACTED <mailto:erlang-patches@REDACTED>
>>>>>>        http://erlang.org/mailman/listinfo/erlang-patches
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> erlang-patches mailing list
>>>>> erlang-patches@REDACTED
>>>>> http://erlang.org/mailman/listinfo/erlang-patches
>>>>>
>>>>>
>>>> _______________________________________________
>>>> erlang-patches mailing list
>>>> erlang-patches@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-patches
>>>
>>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
>


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

More information about the erlang-patches mailing list