4 ms·

The optimal number of core string types for a language to have is one. Python got to two, and the community decided that was enough of a PITA to merit a breaki

The optimal number of core string types for a language to have is one. Python got to two, and the community decided that was enough of a PITA to merit a breaking change in the language in order to get back down to one. C++ also has two, but we put up with it because it's C++ so really we're just thankful it's not three or four. Five is so far beyond the pale that it is absolutely reasonable to hyperbolize it as "zillions".

tene 10y ago
ByteString isn't really a "string" type; it's a byte buffer. It's not about text. I think that it's entirely reasonable to have a dedicated "Text" type that works with decoded human text, separate from buffers of bytes. I also think that it's entirely reasonable to have lazy and strict variants of core data types; they have very different time/space tradeoffs. It's definitely frustrating that the core language definition has a data type "String" that's a pretty bad choice for almost any application (it's a linked list of characters), and that's a legitimate problem, but I think an accurate characterization of the real problem with string data types in Haskell is much more like "You should be able to use Text everywhere to deal with decoded unicode text, but for unfortunate legacy reasons you have to use String to interact with large parts of the standard library". Treating all bytes as if they happen to accidentally represent utf-8 encoded unicode text would be a big mistake; there's significant advantages to representing text and byte buffers separately. They are very different things. Choosing to support only strict or only lazy handling of byte buffers or text would be quite unfortunate; there are significant advantages to both for different algorithms and use cases, and encoding the difference in the type system seems entirely reasonable to me. I'm curious which of these you disagree with. Would you prefer that Text and ByteString be merged into one data type, so that the compiler doesn't consider it a mistake to treat arbitrary bytes as if it were text without specifying any encoding? Would you prefer that Text and/or ByteString discard support for lazy representation, or for strict representation?
bennofs 10y ago
Doesn't python3 have both bytes and str, the equavilent of ByteString and Text?
twic 10y ago
Rust has six, plus the Path types: http://www.suspectsemantics.com/blog/2016/03/27/string-types-in-rust/ http://www.suspectsemantics.com/blog/2016/03/27/string-types... I would say it's actually justified in that.
- kibwen 10y ago
  Those aren't string types, they're buffers for platform-dependent system interoperation. When used, the goal is to convert them to String as soon as possible. If one considers those to be string types, then Vec<u8>, Vec<16>, and Vec<32> would be considered string types as well (in addition to both fixed-size arrays and unsafe pointers to the same).
marcosdumay 10y ago
Haskell has 1 unnecessary string type: String. All the other types provide specific functionality that you won't get otherwise. (While String is there only because it is easy to use.) If you really don't care about that extra functionality, just keep with strict Text, and be done with that. Now, if the perfect number of string types is 1, why couldn't you name any language with that number. By the way, Java also has two string types, as does .Net. Python still has 2 types, they just don't coerce into each other anymore, and I've probably seen a dozen C++ string types already.
- deleted 10y ago
  [deleted]
- riwsky 10y ago
  I think the ancestor post was referring to python 2's separate str and unicode types, not bytes vs str.
  - marcosdumay 10y ago
    If he does not think Python's bytes vs. str is confusing, he has no basis to claim Haskell's Text vs. ByteString is confusing either.
    - dllthomas 10y ago
      "ByteString has String in the name" is a basis, however narrow...

tene 10y ago

ByteString isn't really a "string" type; it's a byte buffer. It's not about text. I think that it's entirely reasonable to have a dedicated "Text" type that works with decoded human text, separate from buffers of bytes. I also think that it's entirely reasonable to have lazy and strict variants of core data types; they have very different time/space tradeoffs. It's definitely frustrating that the core language definition has a data type "String" that's a pretty bad choice for almost any application (it's a linked list of characters), and that's a legitimate problem, but I think an accurate characterization of the real problem with string data types in Haskell is much more like "You should be able to use Text everywhere to deal with decoded unicode text, but for unfortunate legacy reasons you have to use String to interact with large parts of the standard library". Treating all bytes as if they happen to accidentally represent utf-8 encoded unicode text would be a big mistake; there's significant advantages to representing text and byte buffers separately. They are very different things. Choosing to support only strict or only lazy handling of byte buffers or text would be quite unfortunate; there are significant advantages to both for different algorithms and use cases, and encoding the difference in the type system seems entirely reasonable to me. I'm curious which of these you disagree with. Would you prefer that Text and ByteString be merged into one data type, so that the compiler doesn't consider it a mistake to treat arbitrary bytes as if it were text without specifying any encoding? Would you prefer that Text and/or ByteString discard support for lazy representation, or for strict representation?

bennofs 10y ago

Doesn't python3 have both bytes and str, the equavilent of ByteString and Text?

twic 10y ago

Rust has six, plus the Path types: http://www.suspectsemantics.com/blog/2016/03/27/string-types-in-rust/ http://www.suspectsemantics.com/blog/2016/03/27/string-types... I would say it's actually justified in that.

kibwen 10y ago
Those aren't string types, they're buffers for platform-dependent system interoperation. When used, the goal is to convert them to String as soon as possible. If one considers those to be string types, then Vec<u8>, Vec<16>, and Vec<32> would be considered string types as well (in addition to both fixed-size arrays and unsafe pointers to the same).

marcosdumay 10y ago

Haskell has 1 unnecessary string type: String. All the other types provide specific functionality that you won't get otherwise. (While String is there only because it is easy to use.) If you really don't care about that extra functionality, just keep with strict Text, and be done with that. Now, if the perfect number of string types is 1, why couldn't you name any language with that number. By the way, Java also has two string types, as does .Net. Python still has 2 types, they just don't coerce into each other anymore, and I've probably seen a dozen C++ string types already.

deleted 10y ago
[deleted]
riwsky 10y ago
I think the ancestor post was referring to python 2's separate str and unicode types, not bytes vs str.
- marcosdumay 10y ago
  If he does not think Python's bytes vs. str is confusing, he has no basis to claim Haskell's Text vs. ByteString is confusing either.
  - dllthomas 10y ago
    "ByteString has String in the name" is a basis, however narrow...