[erlang-patches] [patch] binary to/from integer
Björn-Egil Dahlberg
egil@REDACTED
Fri Jan 11 15:01:31 CET 2013
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.
// Björn-Egil
>
>
> bengt
>
> On Thu, 2013-01-10 at 23:05 +0100, Loïc Hoguin wrote:
>> 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
>>>
>>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
>
>
More information about the erlang-patches
mailing list