String != [Char]

[Simon Marlow]

> The primary argument is to not break something that works well for most
> purposes, including teaching, at a huge cost of backwards compatibility
> for marginal if any real benefits.

I'm persuaded by this argument.  And I'm glad that teachers are speaking up in this debate - it's hard to get a balanced discussion on an obscure mailing list.

So I'm far from convinced that [Char] is a bad default for the String type.  But it's important that as far as possible Text should not be a second class citizen, so I'd support adding OverloadedStrings to the language, and maybe looking at overloading some of the String APIs in the standard libraries.

Remember that FilePath is not part of the debate, since neither [Char] nor Text are correct representations of FilePath.

If we want to do an evaluation of the pedagogical value of [Char] vs. Text, I suggest writing something like a regex matcher in both and comparing the two.
 
One more thing: historically, performance considerations have been given a fairly low priority in the language design process for Haskell, and rightly so.  That doesn't mean performance has been ignored altogether (for example, seq), but it is almost never the case that a concession in other language design principles (e.g. consistency, simplicity) is made for performance reasons alone.  We should remember, when thinking about changes to Haskell, that Haskell is the way it is because of this uncompromising attitude, and we should be glad that Haskell is not burdened with (many) legacy warts that were invented to work around performance problems that no longer exist.  I'm not saying that this means we should ignore Text as a performance hack, just that performance should not come at the expense of good language design.

Cheers,
	Simon