Quantcast

Erlang basic doubts about String, message passing and context switching overhead

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Erlang basic doubts about String, message passing and context switching overhead

Steve Davis

You would think that, by now, computer science would have a decent answer to how to deal with text.

All answers (from anyplace anyblog anylist) I have heard so far basically… suck.

Why is that? What are the missing ingredients to a real solution?

The word “string” for me has long been a dirty word.

/s

(Political aside: *spits on all that “emoji” crap* :-) )

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Jesper Louis Andersen-2
Strings are really just streams of bytes.

Streams of bytes are the ubiquitous data representation format. It can represent anything you like. The problem is that with the vast generality comes lack of precision. In order to handle the string, you need to interpret its contents. You that with a spectrum of string manipulation techniques: splitting, converting to other types, regular expression matching, LALR(1) parsing and so on. The goal is to take the stream of bytes into some deeper structure which you can manipulate in the program. Squint your eyes enough, and all programs are string processing.

Once you start realizing everything is basically a variant of string processing, you see why it must be hard to build a good solution for. Your solution is at some end of the spectrum, which makes it excellent for handling some problems, but makes it hard to handle others. Very general solutions to the processing problem (LALR(1) parsers, etc) are not the easiest to get going on smaller problems.

Hence most processing is complicated because it requires you to pick the right kind of data processing abstraction in addition to solving the problem itself.

Natural text is hard because there is very little formal structure in it. So you have to use approximative methods, Machine Learning, etc. Context Free text is easier to manage, but few people do it correctly and write a parser for it. Rather, they tend to try to work directly on the string (jokingly called "stringly typed programming").

Is Erlang bad at string processing? Yes and no. OCaml processes strings much faster than Erlang in the common case because it is a compiled language and can run directly as machine code. OTOH, if you have to look at every byte in a data stream, chances are you are bound not by the CPU time, but the time it takes to get data close to the CPU from DRAM. As for the API availability, it all depends on how good you are at using functional programming I guess. I rarely feel I lack certain API functions in Erlang when handling strings. I'd be keen to look into woes you've had in the past with things that were unwieldy to handle.

On Thu, Jan 12, 2017 at 2:50 AM Steve Davis <[hidden email]> wrote:

You would think that, by now, computer science would have a decent answer to how to deal with text.

All answers (from anyplace anyblog anylist) I have heard so far basically… suck.

Why is that? What are the missing ingredients to a real solution?

The word “string” for me has long been a dirty word.

/s

(Political aside: *spits on all that “emoji” crap* :-) )

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Richard A. O'Keefe-2


On 13/01/17 8:56 AM, Jesper Louis Andersen wrote:
> Strings are really just streams of bytes.

That was true a long time ago.  Maybe.
But it isn't anywhere near accurate as a description
of Unicode:
  - Unicode is made of 21-bit code points, not bytes.
  - Most possible code points are not defined.
  - Some of those that are defined are defined as
    "it is illegal to use this".
  - Unicode sequences have *structure*; it is simply
    not the case that every sequence of allowable
    Unicode code points is a legal Unicode string.
  - As a special case of that, if s is a non-empty
    valid Unicode string, it is not true that every
    substring of s is a valid Unicode string.

In case you were thinking of UTF-8, not all byte
sequences are valid UTF-8.

Byte streams are as important as you say, but it's
really hard to see the software for a radar or a
radio telescope as processing strings...

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Jesper Louis Andersen-2
Richard is indeed right, depending on what your definition of "String" is.

If a "String" is "An array of characters from some alphabet", then you need to take into account Strings are Unicode codepoints in practice. This is also the most precise definition from a technical point of view.

When I wrote my post, I was--probably incorrectly--assuming the older notion of a "String" where the representation is either ASCII or something like ISO-8859-15. In this case, a string coincides with a stream of bytes.

Data needs parsing. A lot of data comes in as some kind of stringy representation: UTF-8, byte array (binary), and so on.

And of course, that isn't the whole story, since there are examples of input which are not string-like in their forms.


On Fri, Jan 13, 2017 at 2:34 AM Richard A. O'Keefe <[hidden email]> wrote:


On 13/01/17 8:56 AM, Jesper Louis Andersen wrote:
> Strings are really just streams of bytes.

That was true a long time ago.  Maybe.
But it isn't anywhere near accurate as a description
of Unicode:
  - Unicode is made of 21-bit code points, not bytes.
  - Most possible code points are not defined.
  - Some of those that are defined are defined as
    "it is illegal to use this".
  - Unicode sequences have *structure*; it is simply
    not the case that every sequence of allowable
    Unicode code points is a legal Unicode string.
  - As a special case of that, if s is a non-empty
    valid Unicode string, it is not true that every
    substring of s is a valid Unicode string.

In case you were thinking of UTF-8, not all byte
sequences are valid UTF-8.

Byte streams are as important as you say, but it's
really hard to see the software for a radar or a
radio telescope as processing strings...


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Steve Davis

On Jan 13, 2017, at 6:20 AM, Jesper Louis Andersen <[hidden email]> wrote:

depending on what your definition of "String" is

..and that’s the problem with strings.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Joe Armstrong-2
When I teach programming I always talk about the distinction between
'strings' and string literals. Think that the two are the same is a big mistake.

In Erlang ' "aaa" ' is a 'string literal' and NOT a string. String
literals in most programming
languages are sequences of characters interposed between ' " ' characters.

If I say (in Erlang)

     X = "aaaa"

Then to the right hand side of the equals we have a string literal.
The parser turns this
into some internal form which is stored in the variable X - thereafter
we can speak of
value of X as being a "string", it's actually defined to be a list of
integers, where each
integer represents a single character.

In C

    x = "aaaa"

the internal representation is *entirely different* - this gets turned
into a zero terminated sequence of chas. Most (but not all) C
compilers store chars in 8 bit bytes
so if your natural language has more than 256 characters problems occur.

Enter UTF8 and friends - these are just smart ways of encoding large
integers (ie characters > 256) into multi byte sequences. Then we have
Unicode which has mappings from
natural language character sets onto integers and complex rules for
overlaying and flowing
characters.

Erlang takes the view that the internal representation of a string
literal should be a list of integers - and since Erlang integers are
bignums then any character in any language can be
represented as a single integer in such a list - so far so good.

The problem now comes when we want to convert from a natural language
text into an Erlang string,  and for manipulating strings, and for
this a number of libraries are available.

People complain about string handling in Erlang, but these complaints
usually seem to
reflect the fact that the libraries that manipulate strings and the
escape conventions used
in string literals differ from those in other programming languages.

String handling in all languages is one unholy mess, where the stupid
conventions in one language are copied by later languages.

For example, English has a start-quote and end-quote symbol and they *differ*.

"This editor,"  I think, "gets quotes wrong" [1] - amazing - how many
programmers has
Google got? - and they can't get quotes right.

Text manipulation on a computer should be far easier than it is.

Cheers

/Joe

[1] Google's Chrome browser







On Fri, Jan 13, 2017 at 2:10 PM, Steve Davis
<[hidden email]> wrote:

>
> On Jan 13, 2017, at 6:20 AM, Jesper Louis Andersen
> <[hidden email]> wrote:
>
> depending on what your definition of "String" is
>
>
> ..and that’s the problem with strings.
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Steve Davis
In reply to this post by Jesper Louis Andersen-2

> On Jan 12, 2017, at 1:56 PM, Jesper Louis Andersen <[hidden email]> wrote:
> Is Erlang bad at string processing?

Yes. Every language is bad at "string processing”.

IMHO a better question is: Is Erlang bad at text processing?

No. You just need to realize that there’s *no such thing* as a string in erlang, and keep ill-specified text binaries as binaries. Then you can use the magic of (cautious and limited) regex for tokenization and binary syntax (which is ***truly wonderful***) for parsing.

So do I have problems with text in Erlang? No, it’s far better for that than any other language I’ve used (and I’ve used quite a few).

Strings suck as a way to think about text. That’s the sum of it.

My 2c on all this.

:-)

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Michał Muskała
In reply to this post by Jesper Louis Andersen-2

I fully agree there are no languages that deal with strings perfectly. That said there are those that are better at it and those that aren't so good. A language, where I need to look for a library to upcase or downcase my own name, fits into the second group in my book.


Michał.

On 13 Jan 2017, 13:20 +0100, Jesper Louis Andersen <[hidden email]>, wrote:
Richard is indeed right, depending on what your definition of "String" is.

If a "String" is "An array of characters from some alphabet", then you need to take into account Strings are Unicode codepoints in practice. This is also the most precise definition from a technical point of view.

When I wrote my post, I was--probably incorrectly--assuming the older notion of a "String" where the representation is either ASCII or something like ISO-8859-15. In this case, a string coincides with a stream of bytes.

Data needs parsing. A lot of data comes in as some kind of stringy representation: UTF-8, byte array (binary), and so on.

And of course, that isn't the whole story, since there are examples of input which are not string-like in their forms.


On Fri, Jan 13, 2017 at 2:34 AM Richard A. O'Keefe <[hidden email]> wrote:


On 13/01/17 8:56 AM, Jesper Louis Andersen wrote:
> Strings are really just streams of bytes.

That was true a long time ago.  Maybe.
But it isn't anywhere near accurate as a description
of Unicode:
  - Unicode is made of 21-bit code points, not bytes.
  - Most possible code points are not defined.
  - Some of those that are defined are defined as
    "it is illegal to use this".
  - Unicode sequences have *structure*; it is simply
    not the case that every sequence of allowable
    Unicode code points is a legal Unicode string.
  - As a special case of that, if s is a non-empty
    valid Unicode string, it is not true that every
    substring of s is a valid Unicode string.

In case you were thinking of UTF-8, not all byte
sequences are valid UTF-8.

Byte streams are as important as you say, but it's
really hard to see the software for a radar or a
radio telescope as processing strings...

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

John Doe
Indeed, unicode upercase/lowercsase is one of the most essential features of string which don't exist yet in erlang stdlib. I'm aware about problems with some letters and scripts, such as german SS or turkish I, but still having upper/lower in stdlib is the must, IMO. The problem is that uppercase/lowercase would require support of unicode normalization.

2017-01-14 1:34 GMT+03:00 Michał Muskała <[hidden email]>:

I fully agree there are no languages that deal with strings perfectly. That said there are those that are better at it and those that aren't so good. A language, where I need to look for a library to upcase or downcase my own name, fits into the second group in my book.


Michał.

On 13 Jan 2017, 13:20 +0100, Jesper Louis Andersen <[hidden email]>, wrote:
Richard is indeed right, depending on what your definition of "String" is.

If a "String" is "An array of characters from some alphabet", then you need to take into account Strings are Unicode codepoints in practice. This is also the most precise definition from a technical point of view.

When I wrote my post, I was--probably incorrectly--assuming the older notion of a "String" where the representation is either ASCII or something like ISO-8859-15. In this case, a string coincides with a stream of bytes.

Data needs parsing. A lot of data comes in as some kind of stringy representation: UTF-8, byte array (binary), and so on.

And of course, that isn't the whole story, since there are examples of input which are not string-like in their forms.


On Fri, Jan 13, 2017 at 2:34 AM Richard A. O'Keefe <[hidden email]> wrote:


On 13/01/17 8:56 AM, Jesper Louis Andersen wrote:
> Strings are really just streams of bytes.

That was true a long time ago.  Maybe.
But it isn't anywhere near accurate as a description
of Unicode:
  - Unicode is made of 21-bit code points, not bytes.
  - Most possible code points are not defined.
  - Some of those that are defined are defined as
    "it is illegal to use this".
  - Unicode sequences have *structure*; it is simply
    not the case that every sequence of allowable
    Unicode code points is a legal Unicode string.
  - As a special case of that, if s is a non-empty
    valid Unicode string, it is not true that every
    substring of s is a valid Unicode string.

In case you were thinking of UTF-8, not all byte
sequences are valid UTF-8.

Byte streams are as important as you say, but it's
really hard to see the software for a radar or a
radio telescope as processing strings...

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Loïc Hoguin-3
We need support for locales before we can do proper operations on text.
Just Unicode isn't enough.

On 01/14/2017 03:18 PM, John Doe wrote:

> Indeed, unicode upercase/lowercsase is one of the most essential
> features of string which don't exist yet in erlang stdlib. I'm aware
> about problems with some letters and scripts, such as german SS or
> turkish I, but still having upper/lower in stdlib is the must, IMO. The
> problem is that uppercase/lowercase would require support of unicode
> normalization.
>
> 2017-01-14 1:34 GMT+03:00 Michał Muskała <[hidden email]
> <mailto:[hidden email]>>:
>
>     I fully agree there are no languages that deal with strings
>     perfectly. That said there are those that are better at it and those
>     that aren't so good. A language, where I need to look for a library
>     to upcase or downcase my own name, fits into the second group in my
>     book.
>
>
>     Michał.
>
>     On 13 Jan 2017, 13:20 +0100, Jesper Louis Andersen
>     <[hidden email]
>     <mailto:[hidden email]>>, wrote:
>>     Richard is indeed right, depending on what your definition of
>>     "String" is.
>>
>>     If a "String" is "An array of characters from some alphabet", then
>>     you need to take into account Strings are Unicode codepoints in
>>     practice. This is also the most precise definition from a
>>     technical point of view.
>>
>>     When I wrote my post, I was--probably incorrectly--assuming the
>>     older notion of a "String" where the representation is either
>>     ASCII or something like ISO-8859-15. In this case, a string
>>     coincides with a stream of bytes.
>>
>>     Data needs parsing. A lot of data comes in as some kind of stringy
>>     representation: UTF-8, byte array (binary), and so on.
>>
>>     And of course, that isn't the whole story, since there are
>>     examples of input which are not string-like in their forms.
>>
>>
>>     On Fri, Jan 13, 2017 at 2:34 AM Richard A. O'Keefe
>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>
>>
>>         On 13/01/17 8:56 AM, Jesper Louis Andersen wrote:
>>         > Strings are really just streams of bytes.
>>
>>         That was true a long time ago.  Maybe.
>>         But it isn't anywhere near accurate as a description
>>         of Unicode:
>>           - Unicode is made of 21-bit code points, not bytes.
>>           - Most possible code points are not defined.
>>           - Some of those that are defined are defined as
>>             "it is illegal to use this".
>>           - Unicode sequences have *structure*; it is simply
>>             not the case that every sequence of allowable
>>             Unicode code points is a legal Unicode string.
>>           - As a special case of that, if s is a non-empty
>>             valid Unicode string, it is not true that every
>>             substring of s is a valid Unicode string.
>>
>>         In case you were thinking of UTF-8, not all byte
>>         sequences are valid UTF-8.
>>
>>         Byte streams are as important as you say, but it's
>>         really hard to see the software for a radar or a
>>         radio telescope as processing strings...
>>
>>     _______________________________________________
>>     erlang-questions mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     http://erlang.org/mailman/listinfo/erlang-questions
>>     <http://erlang.org/mailman/listinfo/erlang-questions>
>
>     _______________________________________________
>     erlang-questions mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://erlang.org/mailman/listinfo/erlang-questions
>     <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Benoit Chesneau-2
someone has to write a good binding (non blocking) of icu :) I think it would be easier than reinventing the wheel. i18n [1] was a good start but looks abandoned these days. Also I disliked the load of resources at startup in ETS: https://github.com/erlang-unicode/i18n

- benoît

On Sat, Jan 14, 2017 at 3:56 PM Loïc Hoguin <[hidden email]> wrote:
We need support for locales before we can do proper operations on text.
Just Unicode isn't enough.

On 01/14/2017 03:18 PM, John Doe wrote:
> Indeed, unicode upercase/lowercsase is one of the most essential
> features of string which don't exist yet in erlang stdlib. I'm aware
> about problems with some letters and scripts, such as german SS or
> turkish I, but still having upper/lower in stdlib is the must, IMO. The
> problem is that uppercase/lowercase would require support of unicode
> normalization.
>
> 2017-01-14 1:34 GMT+03:00 Michał Muskała <[hidden email]
> <mailto:[hidden email]>>:
>
>     I fully agree there are no languages that deal with strings
>     perfectly. That said there are those that are better at it and those
>     that aren't so good. A language, where I need to look for a library
>     to upcase or downcase my own name, fits into the second group in my
>     book.
>
>
>     Michał.
>
>     On 13 Jan 2017, 13:20 +0100, Jesper Louis Andersen
>     <[hidden email]
>     <mailto:[hidden email]>>, wrote:
>>     Richard is indeed right, depending on what your definition of
>>     "String" is.
>>
>>     If a "String" is "An array of characters from some alphabet", then
>>     you need to take into account Strings are Unicode codepoints in
>>     practice. This is also the most precise definition from a
>>     technical point of view.
>>
>>     When I wrote my post, I was--probably incorrectly--assuming the
>>     older notion of a "String" where the representation is either
>>     ASCII or something like ISO-8859-15. In this case, a string
>>     coincides with a stream of bytes.
>>
>>     Data needs parsing. A lot of data comes in as some kind of stringy
>>     representation: UTF-8, byte array (binary), and so on.
>>
>>     And of course, that isn't the whole story, since there are
>>     examples of input which are not string-like in their forms.
>>
>>
>>     On Fri, Jan 13, 2017 at 2:34 AM Richard A. O'Keefe
>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>
>>
>>         On 13/01/17 8:56 AM, Jesper Louis Andersen wrote:
>>         > Strings are really just streams of bytes.
>>
>>         That was true a long time ago.  Maybe.
>>         But it isn't anywhere near accurate as a description
>>         of Unicode:
>>           - Unicode is made of 21-bit code points, not bytes.
>>           - Most possible code points are not defined.
>>           - Some of those that are defined are defined as
>>             "it is illegal to use this".
>>           - Unicode sequences have *structure*; it is simply
>>             not the case that every sequence of allowable
>>             Unicode code points is a legal Unicode string.
>>           - As a special case of that, if s is a non-empty
>>             valid Unicode string, it is not true that every
>>             substring of s is a valid Unicode string.
>>
>>         In case you were thinking of UTF-8, not all byte
>>         sequences are valid UTF-8.
>>
>>         Byte streams are as important as you say, but it's
>>         really hard to see the software for a radar or a
>>         radio telescope as processing strings...
>>
>>     _______________________________________________
>>     erlang-questions mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     http://erlang.org/mailman/listinfo/erlang-questions
>>     <http://erlang.org/mailman/listinfo/erlang-questions>
>
>     _______________________________________________
>     erlang-questions mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://erlang.org/mailman/listinfo/erlang-questions
>     <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Oliver Korpilla
In reply to this post by Michał Muskała
Could the Unicode support in elixir serve as a starting point?

https://hexdocs.pm/elixir/1.3.3/String.html#content

String.upcase/1 and String.downcase/1 seem to be Unicode-aware. And a lot of effort seems have gone in scenarios like this:

"For example, the codepoint “é” is two bytes:

iex> byte_size("é")
2"

Given that both Erlang and elixir are implemented on top of BEAM, the wheel might not need reinventing? I know engineers and programmers love inventing stuff, and this discussion seems to point in that direction, but...

Cheers,
Oliver
 
 

Gesendet: Freitag, 13. Januar 2017 um 23:34 Uhr
Von: "Michał Muskała" <[hidden email]>
An: "Richard A. O'Keefe" <[hidden email]>, "Steve Davis" <[hidden email]>, [hidden email], "Jesper Louis Andersen" <[hidden email]>
Cc: "Erlang Questions" <[hidden email]>
Betreff: Re: [erlang-questions] Erlang basic doubts about String, message passing and context switching overhead

I fully agree there are no languages that deal with strings perfectly. That said there are those that are better at it and those that aren't so good. A language, where I need to look for a library to upcase or downcase my own name, fits into the second group in my book.

Michał.
On 13 Jan 2017, 13:20 +0100, Jesper Louis Andersen <[hidden email]>, wrote:

Richard is indeed right, depending on what your definition of "String" is.
 If a "String" is "An array of characters from some alphabet", then you need to take into account Strings are Unicode codepoints in practice. This is also the most precise definition from a technical point of view.
 When I wrote my post, I was--probably incorrectly--assuming the older notion of a "String" where the representation is either ASCII or something like ISO-8859-15. In this case, a string coincides with a stream of bytes.
 Data needs parsing. A lot of data comes in as some kind of stringy representation: UTF-8, byte array (binary), and so on.
 And of course, that isn't the whole story, since there are examples of input which are not string-like in their forms.
  

On Fri, Jan 13, 2017 at 2:34 AM Richard A. O'Keefe <[hidden email][mailto:[hidden email]]> wrote:

On 13/01/17 8:56 AM, Jesper Louis Andersen wrote:
> Strings are really just streams of bytes.

That was true a long time ago.  Maybe.
But it isn't anywhere near accurate as a description
of Unicode:
  - Unicode is made of 21-bit code points, not bytes.
  - Most possible code points are not defined.
  - Some of those that are defined are defined as
    "it is illegal to use this".
  - Unicode sequences have *structure*; it is simply
    not the case that every sequence of allowable
    Unicode code points is a legal Unicode string.
  - As a special case of that, if s is a non-empty
    valid Unicode string, it is not true that every
    substring of s is a valid Unicode string.

In case you were thinking of UTF-8, not all byte
sequences are valid UTF-8.

Byte streams are as important as you say, but it's
really hard to see the software for a radar or a
radio telescope as processing strings...
 _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Ilya Khaprov

>> Given that both Erlang and elixir are implemented on top of BEAM, the wheel might not need reinventing?

 

Why Elixir implements Unicode in Elixir? You have to rewrite it anyway.

 

Ilya

 

From: [hidden email]
Sent: Saturday, January 14, 2017 06:53 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [erlang-questions] Erlang basic doubts about String, message passing and context switching overhead

 

Could the Unicode support in elixir serve as a starting point?

https://hexdocs.pm/elixir/1.3.3/String.html#content

String.upcase/1 and String.downcase/1 seem to be Unicode-aware. And a lot of effort seems have gone in scenarios like this:

"For example, the codepoint “é” is two bytes:

iex> byte_size("é")
2"

Given that both Erlang and elixir are implemented on top of BEAM, the wheel might not need reinventing? I know engineers and programmers love inventing stuff, and this discussion seems to point in that direction, but...

Cheers,
Oliver
 
 

Gesendet: Freitag, 13. Januar 2017 um 23:34 Uhr
Von: "Michał Muskała" <[hidden email]>
An: "Richard A. O'Keefe" <[hidden email]>, "Steve Davis" <[hidden email]>, [hidden email], "Jesper Louis Andersen" <[hidden email]>
Cc: "Erlang Questions" <[hidden email]>
Betreff: Re: [erlang-questions] Erlang basic doubts about String, message passing and context switching overhead

I fully agree there are no languages that deal with strings perfectly. That said there are those that are better at it and those that aren't so good. A language, where I need to look for a library to upcase or downcase my own name, fits into the second group in my book.

Michał.
On 13 Jan 2017, 13:20 +0100, Jesper Louis Andersen <[hidden email]>, wrote:

Richard is indeed right, depending on what your definition of "String" is.
 If a "String" is "An array of characters from some alphabet", then you need to take into account Strings are Unicode codepoints in practice. This is also the most precise definition from a technical point of view.
 When I wrote my post, I was--probably incorrectly--assuming the older notion of a "String" where the representation is either ASCII or something like ISO-8859-15. In this case, a string coincides with a stream of bytes.
 Data needs parsing. A lot of data comes in as some kind of stringy representation: UTF-8, byte array (binary), and so on.
 And of course, that isn't the whole story, since there are examples of input which are not string-like in their forms.
  

On Fri, Jan 13, 2017 at 2:34 AM Richard A. O'Keefe <[hidden email][mailto:[hidden email]]> wrote:

On 13/01/17 8:56 AM, Jesper Louis Andersen wrote:
> Strings are really just streams of bytes.

That was true a long time ago.  Maybe.
But it isn't anywhere near accurate as a description
of Unicode:
  - Unicode is made of 21-bit code points, not bytes.
  - Most possible code points are not defined.
  - Some of those that are defined are defined as
    "it is illegal to use this".
  - Unicode sequences have *structure*; it is simply
    not the case that every sequence of allowable
    Unicode code points is a legal Unicode string.
  - As a special case of that, if s is a non-empty
    valid Unicode string, it is not true that every
    substring of s is a valid Unicode string.

In case you were thinking of UTF-8, not all byte
sequences are valid UTF-8.

Byte streams are as important as you say, but it's
really hard to see the software for a radar or a
radio telescope as processing strings...
 _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list [hidden email] <a href="http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions"> http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Benoit Chesneau-2
In reply to this post by Oliver Korpilla


On Sat, Jan 14, 2017 at 4:53 PM Oliver Korpilla <[hidden email]> wrote:
Could the Unicode support in elixir serve as a starting point?

https://hexdocs.pm/elixir/1.3.3/String.html#content

String.upcase/1 and String.downcase/1 seem to be Unicode-aware. And a lot of effort seems have gone in scenarios like this:

"For example, the codepoint “é” is two bytes:

iex> byte_size("é")
2"

Given that both Erlang and elixir are implemented on top of BEAM, the wheel might not need reinventing? I know engineers and programmers love inventing stuff, and this discussion seems to point in that direction, but...

Cheers,
Oliver
 

If I remember correctly the unicode support of Elixir is written in elixir and data come from the unicode/icu projects. data resources (codepoints and so on ) are compiled as beam. (I do the dame in my idna lib).

The work may be simpler in using/wrting a nif over the well supported ICU lib thoug. I'm curious about the reasonning that conducted to the current implementation in elixir.

- benoit

 
 

Gesendet: Freitag, 13. Januar 2017 um 23:34 Uhr
Von: "Michał Muskała" <[hidden email]>
An: "Richard A. O'Keefe" <[hidden email]>, "Steve Davis" <[hidden email]>, [hidden email], "Jesper Louis Andersen" <[hidden email]>
Cc: "Erlang Questions" <[hidden email]>
Betreff: Re: [erlang-questions] Erlang basic doubts about String, message passing and context switching overhead

I fully agree there are no languages that deal with strings perfectly. That said there are those that are better at it and those that aren't so good. A language, where I need to look for a library to upcase or downcase my own name, fits into the second group in my book.

Michał.
On 13 Jan 2017, 13:20 +0100, Jesper Louis Andersen <[hidden email]>, wrote:

Richard is indeed right, depending on what your definition of "String" is.
 If a "String" is "An array of characters from some alphabet", then you need to take into account Strings are Unicode codepoints in practice. This is also the most precise definition from a technical point of view.
 When I wrote my post, I was--probably incorrectly--assuming the older notion of a "String" where the representation is either ASCII or something like ISO-8859-15. In this case, a string coincides with a stream of bytes.
 Data needs parsing. A lot of data comes in as some kind of stringy representation: UTF-8, byte array (binary), and so on.
 And of course, that isn't the whole story, since there are examples of input which are not string-like in their forms.
  

On Fri, Jan 13, 2017 at 2:34 AM Richard A. O'Keefe <[hidden email][mailto:[hidden email]]> wrote:

On 13/01/17 8:56 AM, Jesper Louis Andersen wrote:
> Strings are really just streams of bytes.

That was true a long time ago.  Maybe.
But it isn't anywhere near accurate as a description
of Unicode:
  - Unicode is made of 21-bit code points, not bytes.
  - Most possible code points are not defined.
  - Some of those that are defined are defined as
    "it is illegal to use this".
  - Unicode sequences have *structure*; it is simply
    not the case that every sequence of allowable
    Unicode code points is a legal Unicode string.
  - As a special case of that, if s is a non-empty
    valid Unicode string, it is not true that every
    substring of s is a valid Unicode string.

In case you were thinking of UTF-8, not all byte
sequences are valid UTF-8.

Byte streams are as important as you say, but it's
really hard to see the software for a radar or a
radio telescope as processing strings...
 _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

John Doe
Nif would make erlang distribution way less portable than it is now. At the moment erlang compiled on with static openss can be moven just by copying between most modern linux distros of the same bits. ICU is a C++ lib, anything with linkage against libstdc++ is not portable, new versions of GCC break compatibility of libstdc++ quite often.

2017-01-14 19:06 GMT+03:00 Benoit Chesneau <[hidden email]>:


On Sat, Jan 14, 2017 at 4:53 PM Oliver Korpilla <[hidden email]> wrote:
Could the Unicode support in elixir serve as a starting point?

https://hexdocs.pm/elixir/1.3.3/String.html#content

String.upcase/1 and String.downcase/1 seem to be Unicode-aware. And a lot of effort seems have gone in scenarios like this:

"For example, the codepoint “é” is two bytes:

iex> byte_size("é")
2"

Given that both Erlang and elixir are implemented on top of BEAM, the wheel might not need reinventing? I know engineers and programmers love inventing stuff, and this discussion seems to point in that direction, but...

Cheers,
Oliver
 

If I remember correctly the unicode support of Elixir is written in elixir and data come from the unicode/icu projects. data resources (codepoints and so on ) are compiled as beam. (I do the dame in my idna lib).

The work may be simpler in using/wrting a nif over the well supported ICU lib thoug. I'm curious about the reasonning that conducted to the current implementation in elixir.

- benoit

 
 

Gesendet: Freitag, 13. Januar 2017 um 23:34 Uhr
Von: "Michał Muskała" <[hidden email]>
An: "Richard A. O'Keefe" <[hidden email]>, "Steve Davis" <[hidden email]>, [hidden email], "Jesper Louis Andersen" <[hidden email]>
Cc: "Erlang Questions" <[hidden email]>
Betreff: Re: [erlang-questions] Erlang basic doubts about String, message passing and context switching overhead

I fully agree there are no languages that deal with strings perfectly. That said there are those that are better at it and those that aren't so good. A language, where I need to look for a library to upcase or downcase my own name, fits into the second group in my book.

Michał.
On 13 Jan 2017, 13:20 +0100, Jesper Louis Andersen <[hidden email]>, wrote:

Richard is indeed right, depending on what your definition of "String" is.
 If a "String" is "An array of characters from some alphabet", then you need to take into account Strings are Unicode codepoints in practice. This is also the most precise definition from a technical point of view.
 When I wrote my post, I was--probably incorrectly--assuming the older notion of a "String" where the representation is either ASCII or something like ISO-8859-15. In this case, a string coincides with a stream of bytes.
 Data needs parsing. A lot of data comes in as some kind of stringy representation: UTF-8, byte array (binary), and so on.
 And of course, that isn't the whole story, since there are examples of input which are not string-like in their forms.
  

On Fri, Jan 13, 2017 at 2:34 AM Richard A. O'Keefe <[hidden email][mailto:[hidden email]]> wrote:

On 13/01/17 8:56 AM, Jesper Louis Andersen wrote:
> Strings are really just streams of bytes.

That was true a long time ago.  Maybe.
But it isn't anywhere near accurate as a description
of Unicode:
  - Unicode is made of 21-bit code points, not bytes.
  - Most possible code points are not defined.
  - Some of those that are defined are defined as
    "it is illegal to use this".
  - Unicode sequences have *structure*; it is simply
    not the case that every sequence of allowable
    Unicode code points is a legal Unicode string.
  - As a special case of that, if s is a non-empty
    valid Unicode string, it is not true that every
    substring of s is a valid Unicode string.

In case you were thinking of UTF-8, not all byte
sequences are valid UTF-8.

Byte streams are as important as you say, but it's
really hard to see the software for a radar or a
radio telescope as processing strings...
 _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

John Doe
In reply to this post by Benoit Chesneau-2
Also as far as I remember icu works with utf16, so any call to icu requires encoding binary, which is usually usually utf8, to utf16 and then encoding it back to utf8 binary.

2017-01-14 19:06 GMT+03:00 Benoit Chesneau <[hidden email]>:


On Sat, Jan 14, 2017 at 4:53 PM Oliver Korpilla <[hidden email]> wrote:
Could the Unicode support in elixir serve as a starting point?

https://hexdocs.pm/elixir/1.3.3/String.html#content

String.upcase/1 and String.downcase/1 seem to be Unicode-aware. And a lot of effort seems have gone in scenarios like this:

"For example, the codepoint “é” is two bytes:

iex> byte_size("é")
2"

Given that both Erlang and elixir are implemented on top of BEAM, the wheel might not need reinventing? I know engineers and programmers love inventing stuff, and this discussion seems to point in that direction, but...

Cheers,
Oliver
 

If I remember correctly the unicode support of Elixir is written in elixir and data come from the unicode/icu projects. data resources (codepoints and so on ) are compiled as beam. (I do the dame in my idna lib).

The work may be simpler in using/wrting a nif over the well supported ICU lib thoug. I'm curious about the reasonning that conducted to the current implementation in elixir.

- benoit

 
 

Gesendet: Freitag, 13. Januar 2017 um 23:34 Uhr
Von: "Michał Muskała" <[hidden email]>
An: "Richard A. O'Keefe" <[hidden email]>, "Steve Davis" <[hidden email]>, [hidden email], "Jesper Louis Andersen" <[hidden email]>
Cc: "Erlang Questions" <[hidden email]>
Betreff: Re: [erlang-questions] Erlang basic doubts about String, message passing and context switching overhead

I fully agree there are no languages that deal with strings perfectly. That said there are those that are better at it and those that aren't so good. A language, where I need to look for a library to upcase or downcase my own name, fits into the second group in my book.

Michał.
On 13 Jan 2017, 13:20 +0100, Jesper Louis Andersen <[hidden email]>, wrote:

Richard is indeed right, depending on what your definition of "String" is.
 If a "String" is "An array of characters from some alphabet", then you need to take into account Strings are Unicode codepoints in practice. This is also the most precise definition from a technical point of view.
 When I wrote my post, I was--probably incorrectly--assuming the older notion of a "String" where the representation is either ASCII or something like ISO-8859-15. In this case, a string coincides with a stream of bytes.
 Data needs parsing. A lot of data comes in as some kind of stringy representation: UTF-8, byte array (binary), and so on.
 And of course, that isn't the whole story, since there are examples of input which are not string-like in their forms.
  

On Fri, Jan 13, 2017 at 2:34 AM Richard A. O'Keefe <[hidden email][mailto:[hidden email]]> wrote:

On 13/01/17 8:56 AM, Jesper Louis Andersen wrote:
> Strings are really just streams of bytes.

That was true a long time ago.  Maybe.
But it isn't anywhere near accurate as a description
of Unicode:
  - Unicode is made of 21-bit code points, not bytes.
  - Most possible code points are not defined.
  - Some of those that are defined are defined as
    "it is illegal to use this".
  - Unicode sequences have *structure*; it is simply
    not the case that every sequence of allowable
    Unicode code points is a legal Unicode string.
  - As a special case of that, if s is a non-empty
    valid Unicode string, it is not true that every
    substring of s is a valid Unicode string.

In case you were thinking of UTF-8, not all byte
sequences are valid UTF-8.

Byte streams are as important as you say, but it's
really hard to see the software for a radar or a
radio telescope as processing strings...
 _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Benoit Chesneau-2


On Sat, Jan 14, 2017 at 5:23 PM John Doe <[hidden email]> wrote:
Also as far as I remember icu works with utf16, so any call to icu requires encoding binary, which is usually usually utf8, to utf16 and then encoding it back to utf8 binary.


ICU is far more portable than even Erlang is, working on very different platforms and can now be compiled using clang and not only g++. It is handling Unicode 9 and should work with utf8 also but not sure about the details.

Anyway not saying it is better or not hence why I was asking for the reasoning of the Elixir people to come to their solution ;)

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Garrett Smith-5
In reply to this post by Michał Muskała
On Fri, Jan 13, 2017 at 4:34 PM, Michał Muskała <[hidden email]> wrote:
> I fully agree there are no languages that deal with strings perfectly. That
> said there are those that are better at it and those that aren't so good. A
> language, where I need to look for a library to upcase or downcase my own
> name, fits into the second group in my book.

If you're talking about this:

> "hello".upcase()
"HELLO"

vs:

> string:to_upper("hello").
"HELLO"

I would be tempted to rephrase "Erlang is not good for ..." with
"Erlang is not what I am used to for ..."

Some languages invest tremendous effort in programmer convenience and
fit and finish. I think this is terrific! It's one of the major
appeals of Elixir vis-a-vis Erlang and has inspired a huge influx of
creativity and contributions within that ecosystem.

However, when it comes to the merits of a language (and it's
libraries, runtime environments, etc.) there are trade offs
*everywhere* and some of these conveniences come at a high cost. I
don't think "good" and "bad" are nearly specific enough to help inform
our decisions about language adoption.

Now the following is *my very personal opinion* and I'm not grinding
any ax here, extremely happy to live and let live, but this: I don't
particularly find writing function(Arg) (as opposed to Arg.function)
hard, at all - and I *certainly* don't want to pay *any* price in
terms of added complexity or performance degradation for object
oriented ish semantics or features. That's me though. I know a lot of
people really like their language features and thank goodness we have
options!
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

John Doe
>string:to_upper("hello").

This function works for ASCII only. That's the problem. MICHAł = string:to_upper("Michał").

2017-01-14 19:36 GMT+03:00 Garrett Smith <[hidden email]>:
On Fri, Jan 13, 2017 at 4:34 PM, Michał Muskała <[hidden email]> wrote:
> I fully agree there are no languages that deal with strings perfectly. That
> said there are those that are better at it and those that aren't so good. A
> language, where I need to look for a library to upcase or downcase my own
> name, fits into the second group in my book.

If you're talking about this:

> "hello".upcase()
"HELLO"

vs:

> string:to_upper("hello").
"HELLO"

I would be tempted to rephrase "Erlang is not good for ..." with
"Erlang is not what I am used to for ..."

Some languages invest tremendous effort in programmer convenience and
fit and finish. I think this is terrific! It's one of the major
appeals of Elixir vis-a-vis Erlang and has inspired a huge influx of
creativity and contributions within that ecosystem.

However, when it comes to the merits of a language (and it's
libraries, runtime environments, etc.) there are trade offs
*everywhere* and some of these conveniences come at a high cost. I
don't think "good" and "bad" are nearly specific enough to help inform
our decisions about language adoption.

Now the following is *my very personal opinion* and I'm not grinding
any ax here, extremely happy to live and let live, but this: I don't
particularly find writing function(Arg) (as opposed to Arg.function)
hard, at all - and I *certainly* don't want to pay *any* price in
terms of added complexity or performance degradation for object
oriented ish semantics or features. That's me though. I know a lot of
people really like their language features and thank goodness we have
options!
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erlang basic doubts about String, message passing and context switching overhead

Oliver Korpilla
Hello,

to be fair, the Polish special "ł" is easy to miss for everybody not versed with the language when doing a visual scan. ;) Which is kind of the point of lots of Unicode code points.

But as John Doe pointed out, this is indeed what this is about. It actually Unicode-aware in its conversions which I think is also shown in the examples.

Cheers,
Oliver 

Gesendet: Samstag, 14. Januar 2017 um 18:08 Uhr
Von: "John Doe" <[hidden email]>
An: Kein Empfänger
Cc: "Erlang Questions" <[hidden email]>
Betreff: Re: [erlang-questions] Erlang basic doubts about String, message passing and context switching overhead

>string:to_upper("hello").
 
This function works for ASCII only. That's the problem. MICHAł = string:to_upper("Michał").
 
2017-01-14 19:36 GMT+03:00 Garrett Smith <[hidden email][mailto:[hidden email]]>:On Fri, Jan 13, 2017 at 4:34 PM, Michał Muskała <[hidden email][mailto:[hidden email]]> wrote:
> I fully agree there are no languages that deal with strings perfectly. That
> said there are those that are better at it and those that aren't so good. A
> language, where I need to look for a library to upcase or downcase my own
> name, fits into the second group in my book.

If you're talking about this:

> "hello".upcase()
"HELLO"

vs:

> string:to_upper("hello").
"HELLO"

I would be tempted to rephrase "Erlang is not good for ..." with
"Erlang is not what I am used to for ..."

Some languages invest tremendous effort in programmer convenience and
fit and finish. I think this is terrific! It's one of the major
appeals of Elixir vis-a-vis Erlang and has inspired a huge influx of
creativity and contributions within that ecosystem.

However, when it comes to the merits of a language (and it's
libraries, runtime environments, etc.) there are trade offs
*everywhere* and some of these conveniences come at a high cost. I
don't think "good" and "bad" are nearly specific enough to help inform
our decisions about language adoption.

Now the following is *my very personal opinion* and I'm not grinding
any ax here, extremely happy to live and let live, but this: I don't
particularly find writing function(Arg) (as opposed to Arg.function)
hard, at all - and I *certainly* don't want to pay *any* price in
terms of added complexity or performance degradation for object
oriented ish semantics or features. That's me though. I know a lot of
people really like their language features and thank goodness we have
options!

_______________________________________________
erlang-questions mailing list
[hidden email][mailto:[hidden email]]
http://erlang.org/mailman/listinfo/erlang-questions_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
123
Loading...