[erlang-patches] [patch] binary to/from integer
Bengt Kleberg
bengt.kleberg@REDACTED
Fri Jan 11 09:33:48 CET 2013
Greetings,
FWIW I would like to not autoimport any more functions. The existing
ones are confusing enough when reading up on new code.
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
> >
>
>
More information about the erlang-patches
mailing list