[Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler)

[Tobias Dammers]

FWIW, C++ has:

- char* and const char*, inherited from C
- wchar_t*, const wchar_t*
- the above, but with an explicit length passed along as a separate argument
- std::string
- std::wstring (is that what it's called?)
- various string implementations, provided by platform APIs and frameworks
(QString, LPTCHAR, and other nonsense)

And they all suck - most are really just byte arrays, some try to implement
Unicode but fall short, and the ones that do it mostly right are specific
to a sub-ecosystem. It's a mess.

And do I need to mention PHP? That one doesn't have a useful string type at
all, and also lacks the language feature to build it yourself - you're
stuck with broken semantics either way, best you can hope for is that they
are only mildly broken and you can get away with it.

C, by the way, shares C++'s problem, except that it doesn't even come with
a string type that does bounds checking.

And finally: while Haskell makes you choose between "byte array", "string",
and "list of code points", this isn't really awfully different from
languages like Java or C#, where you make a similar choice (string?
StringBuilder? byte[]?), except that the default is saner (for historical
reasons). Well, that, and that there are lazy flavors of the packed string
amd bytestring types, which has nothing to do with string type choices and
everything with defaulting to and leveraging non-strict semantics.

On Sep 30, 2016 8:17 AM, "Joachim Durchholz" <jo at durchholz.org> wrote:

> Am 30.09.2016 um 04:16 schrieb Richard A. O'Keefe:
>
>>
>> On 30/09/16 4:18 AM, Joachim Durchholz wrote:
>>
>>> Each language does define its preferred string representation.
>>>
>>
>> Java again:  it has *two* string representations baked into the
>> language.
>>
>
> There is a single standard representation.
> I'm not even aware of a second one, and I've been programming Java for
> quite a while now.
>
> Unless you mean StringBuilder/StringBuffer (that would be three String
> types then). However, these classes are by no means "preferred" in
> practice: the vast majority of APIs demands and returns String objects.
>
> Even then, Java has its preferred string representation nailed down pretty
> strongly: a hidden array of 16-bit Unicode code points, referenced by a
> descriptor object (the actual String), immutable.
>
> The Smalltalk system I use most has
>>  - read-only strings (preferred)
>>  - unique read-only strings
>>  - mutable strings
>>  - substrings (positionable read-only slices)
>>  - extensible strings
>>  - streams over strings
>>  - lazy concatenations of strings
>>  - read-only byte arrays viewed as strings
>>  - mutable byte arrays viewed as strings
>>
>
> Ah, Smalltalk. I haven't looked at that in ages.
> I'll give you that these classes all exist, but I am not sure whether a
> Smalltalk programmer would consider them all equivalent or not.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160930/44a59dc0/attachment.html>