
The Haskell String Situation - paulddraper
http://www.stephendiehl.com/posts/strings.html
======
triska
Regarding the following quote about type String = [Char]:

“ _This is not only a bad representation, it’s quite possibly the least
efficient (non-contrived) representation of text data possible and has
horrible performance in both time and space._ ”

It is true: This is slow if String is _internally_ implemented so _naively_
that it is "really" a list of characters. However, better internal
representations are possible, i.e., internal handling of strings _as if_ they
were lists of characters, so that a String appears _to Haskell code_ as a
perfectly "normal" list, while _internally_ being represented much more
efficiently as _a sequence of raw bytes_.

In other words, the fact that String has this specific type (i.e., [Char])
_does not_ mean that it needs to be implemented in the most naive way possible
by the Haskell compiler or interpreter.

Prolog is in a very similar situation:

For convenience to Prolog programmers, strings in double quotes (such as
"abc") ought to be interpreted as _lists of characters_ (such as [a,b,c]). So,
_to Prolog code_ , strings should appear as if they were "normal" lists. This
makes them amenable to Prolog's built-in parsing mechanisms and many
predicates over lists that are already available.

At the same time, strings should be _internally_ represented more efficiently,
as sequences of bytes in memory.

Recently, Mark Thom has expressed his interest in implementing such a solution
in Scryer Prolog:

[https://github.com/mthom/scryer-
prolog/issues/95](https://github.com/mthom/scryer-prolog/issues/95)

The same idea may be applicable to Haskell, to combine convenience with
efficiency when handling strings.

