Long live String = [Char] (Was: Re: String != [Char])

[Henrik Nilsson]

Hi all,

Thomas Schilling wrote:

 > I think most here agree that the main advantage of the current
 > definition is only pedagogical.

But that in itself is not a small deal. In fact, it's a pretty
major advantage.

Moreover, the utter simplicity of String = [Char] is a benefit
in its own right. Let's not forget that this, in practice,
across all Haskell applications, works just fine in the vast
majority of cases.

I get the sense that the proponents for deprecating, and ultimately
get rid of, String = [Char], are suggesting that this would lead
to noticeable performance improvements across the board by virtue
of preventing programmers from accidentally making a poor choice
of data structure for representing string. But I conjecture that
the performance impact of switching form e.g. String to Text at
the level of complete applications would be negligible in most
cases, simply because most Haskell applications are not dominated
by heavy-duty string processing. And those that are, probably
already uses something like Text, and were written be people
who know a thing or two about appropriate choice of data structures
anyway.

As to teaching:

 > I don't really
 > think that having an abstract type is such a big problem for teaching.
 > You can do string processing by doing (pack . myfunction . unpack)

Here at Nottingham, we're teaching all our 1st-year undergraduates
Haskell. It works, but it is a challenge, and, alas, far from everyone
"gets" it. And this is despite the module being taught by one of
the leading and most experienced Haskell educators (and text book
author), Graham Hutton.

Without starting an endless discussion about how to best teach
programming languages in general and Haskell in particular to
(near) beginners, I dare say that idioms like the one suggested
above would do nothing to help.

String != [Char] would break no end of code, text books, tutorials,
lecture slides, would not help with teaching Haskell, all
for very little if any benefit in the grand scheme of things.

So let's not go there.

On the other hand, a standardised, well thought-out, API for
high-performance strings and appropriate mechanisms such
as a measure of overloading to make it easy and palatable to
use, and that work alongside the present String = [Char], would be a
good thing.

All the best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk