[erlang-questions] unexpected result of term_to_binary

[Robert Virding]

While Erlang's meaning of 'string' is not the same as in many languages Erlang has always been extremely explicit and clear about what an Erlang 'string' is, it's even mentioned in the original Erlang book from 1993 (page 20). It is a list of characters, originally latin1 but these days unicode codepoints. Whether this is a good or bad way of representing strings is another question, I see both benefits and problems with it.

So I don't see it as being dishonest, just different from many languages.

Robert

----- Original Message -----
> From: "Steve Davis" <steven.charles.davis@REDACTED>
> To: "Robert Virding" <robert.virding@REDACTED>
> Cc: "Erlang Questions" <erlang-questions@REDACTED>, "Richard O'Keefe" <ok@REDACTED>
> Sent: Tuesday, 22 January, 2013 8:18:44 PM
> Subject: Re: [erlang-questions] unexpected result of term_to_binary
> 
> Let's just say that I'm now sorry I asked the question in the first
> place. I have a decent, unambiguous solution to the issue.
> 
> However, to name that byte flag STRING_EXT is simply dishonest and
> misleading.
> 
> And apart from erl_scan that Ulf mentioned, consider the meaning of
> this module for erlang: http://www.erlang.org/doc/man/string.html
> 
> Finally, if you search this list you'll see I have a history of
> promoting the revocation of the whole concept of a "string" in
> erlang.
> 
> I don't see how it's possible to deny the existence of this concept
> since it is plainly obvious that the platform does makes implicit
> decisions about text as soon as you type [65,66,67] in the REPL.
> 
> BR,
> /s
> 
> On Jan 22, 2013, at 11:35 AM, Robert Virding
> <robert.virding@REDACTED> wrote:
> 
> > I don't see the problem. Erlang doesn't have strings, it only has
> > lists of integers so unless you start tagging things there is no
> > safe way to differentiate between them. As a general list can be a
> > list of anything so the encoding must be able to handle this.
> > However, the encoding special cases a list of small (<256)
> > integers and uses a more compact representation. That it calls it
> > a STRING_EXT doesn't really mean anything, they could just as well
> > have called it LIST_OF_SMALL_INTEGER_EXT instead. The description
> > of STRING_EXT actually says this:
> > 
> > "String does NOT have a corresponding Erlang representation, but is
> > an optimization for sending lists of bytes (integer in the range
> > 0-255) more efficiently over the distribution."
> > 
> > So why not just treat it as such?
> > 
> > Robert
> > 
> > ----- Original Message -----
> >> From: "Steve Davis" <steven.charles.davis@REDACTED>
> >> To: "Richard O'Keefe" <ok@REDACTED>
> >> Cc: "Erlang Questions" <erlang-questions@REDACTED>
> >> Sent: Tuesday, 22 January, 2013 2:29:54 PM
> >> Subject: Re: [erlang-questions] unexpected result of
> >> term_to_binary
> >> 
> >> Because I was writing an ETF decoder for a language that does make
> >> a
> >> distinction between strings and arrays of integers, and wanted to
> >> avoid constraints on the kinds of terms that could be sent from
> >> the
> >> erlang side of things.
> >> 
> >> On Jan 21, 2013, at 11:23 PM, "Richard O'Keefe"
> >> <ok@REDACTED>
> >> wrote:
> >> 
> >>> 
> >>> On 22/01/2013, at 8:38 AM, Steve Davis wrote:
> >>> 
> >>>> The following appears to encode lists of integers as strings
> >>>> (?!?):
> >>>> 
> >>>> Is there a reason for this that I'm missing?
> >>> 
> >>> Why do you _care_ what the encoding is as long as it decodes
> >>> correctly?
> >> 
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED
> >> http://erlang.org/mailman/listinfo/erlang-questions
> >> 
> 
>