quoting

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

quoting

Joe Armstrong (AL/EAB)
Comments:

        1) printing binaries <<"...">> properly has had a strange effect on my programming
        I now use them far more than I ever did before - this is because they get printed
        nicely - I think I was often using atoms just because I could see them when my
        program failed.

        2) We don't need or want a string type. That's what a binary is.

        IMHO we need a character type - so we can distinguish $a from 97.

      We also need a small number of BIFs that do string operations on binaries.

        for example split(Binary, Str) -> {Before, After} | no
        (take a binary and split it at a constant string) would be *incredable* useful

        A small number of well-chosen primitive on binaries would be very useful.

        Somebody else can tell the list what these should be - and how yecc and leex can make use of
them :-)

        /Joe

> -----Original Message-----
> From: owner-erlang-questions
> [mailto:owner-erlang-questions]On Behalf Of Vlad Dumitrescu
> XX (LN/EAB)
> Sent: den 29 november 2005 11:47
> To: erlang-questions
> Subject: RE: quoting
>
>
> Hi,
>
> > Change 1 - to io_lib.erl  print binaries containing strings
> > as <<"abc">> as <<"abc">> and NOT
> >            <<97,98,99>>
>
> I think this is nice, but... It is already a little tricky to get the
> proper formatting when handling lists of integers vs strings. Now it
> will be the same with binaries.
>
> I'd like to suggest (like so many before me) that a proper string type
> is introduced. I realize this is more difficult than it looks
> (especially wrt old code), but I think that it would be one of those
> added feature that doesn't require removing something else in order to
> preserve simplicity.
>  
> Regards,
> Vlad
>


Reply | Threaded
Open this post in threaded view
|

quoting

Christian S
This is mostly a me-too message. I too use binaries for strings often,
and feel the lack of a 'binaries' module (like there is a 'string' and
a 'lists' module that are useful for the usual way to do strings). I
feel a jungerl lib idea growing.

So this question goes out to all readers:
What interfaces do you chose to use for your utility functions?

Personally, I use something like this frequently:

skip(<<"abc:def">>, $:) to get <<"def">>

piks(<<"abc:def">>, $:) to get <<"abc">>

divide(<<"abc:def">>, $:) to get {<<"abc">>, <<"def">>} (like joe's
but only single-char divider)

match(Bin, RE) -> regexp:match(binary_to_list(Bin), RE).

part(<<"abcdef">>, 3, 2) -> <<"cd">>.

And I implement the special cases differently every time i reinvent
the code. It is not much code to implement, but a shared code base
means we all call these functions the same thing.

PS.
Using binaries as octet-strings always make me worry about code spaces
that do not fit as super sets of ASCII in 256 code points.
utf8-versions of the above examples seem like at least twice the job
to write, so i never bothered.

PS:
If I could reach the web on ports other than 80 and 8080 I would have
pointed to a erlang wiki page.


Reply | Threaded
Open this post in threaded view
|

quoting

Bengt Kleberg-4
On 2005-11-29 17:26, Christian S wrote:

> This is mostly a me-too message. I too use binaries for strings often,
> and feel the lack of a 'binaries' module (like there is a 'string' and
> a 'lists' module that are useful for the usual way to do strings). I
> feel a jungerl lib idea growing.
>
> So this question goes out to all readers:
> What interfaces do you chose to use for your utility functions?
>
> Personally, I use something like this frequently:
>
> skip(<<"abc:def">>, $:) to get <<"def">>
>
> piks(<<"abc:def">>, $:) to get <<"abc">>
>
> divide(<<"abc:def">>, $:) to get {<<"abc">>, <<"def">>} (like joe's
> but only single-char divider)
>
> match(Bin, RE) -> regexp:match(binary_to_list(Bin), RE).
>
> part(<<"abcdef">>, 3, 2) -> <<"cd">>.

could the names be made more consistent with the existing erlang
libraries by using something like the names in lists module?
dropwhile/2, takewhile/2, sub<list>/3 (replace list with binary or set)

and from string module:
tokens/2


bengt, who thinks tokens is a misleading name, but realise that it would
be really difficult to change.


Reply | Threaded
Open this post in threaded view
|

quoting

Christian S
2005/11/30, Bengt Kleberg <bengt.kleberg>:

> could the names be made more consistent with the existing erlang
> libraries by using something like the names in lists module?
> dropwhile/2, takewhile/2, sub<list>/3 (replace list with binary or set)
>
> and from string module:
> tokens/2
>
>
> bengt, who thinks tokens is a misleading name, but realise that it would
> be really difficult to change.

That's reasonable objections. I was mostly focusing on module
interface, and not so much names.

Via http://www.planeterlang.org/ I noticed the existence of a library
targeting string-use of binaries:

  http://capflam.org/wp-content/files/stream/stream.html

I haven't tried how I like that interface, but at least it is code already
written.


Reply | Threaded
Open this post in threaded view
|

quoting

Thomas Lindgren-5
In reply to this post by Joe Armstrong (AL/EAB)


--- "Joe Armstrong (AL/EAB)"
<joe.armstrong> wrote:

> Comments:
>
> 1) printing binaries <<"...">> properly has had a
> strange effect on my programming
> I now use them far more than I ever did before -
> this is because they get printed
> nicely - I think I was often using atoms just
> because I could see them when my
> program failed.

I think printing binaries in a string-like manner is
very handy. Please do introduce it, OTP.

> IMHO we need a character type - so we can
> distinguish $a from 97.

Richard O'Keefe's postings here on the topic of modern
character sets have made me realize this is not a
trivial issue, alas.

> A small number of well-chosen primitive on binaries
> would be very useful.

Yes.

> Somebody else can tell the list what these should
> be - and how yecc and leex can make use of
> them :-)

My lex.erl in jungerl can already do lexing over
binaries (it works for the examples I have tried, at
least). Only 8-bit characters though. I haven't
measured how this compares to lexing over lists. The
"lex driver" can probably be optimized a bit in both
cases.

Best,
Thomas



               
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/