String literals cause runtime crashes when OverloadedStrings is in effect
There has been a discussion[1] on the web-devel list about
the fate of the IsString instance for Name in the xml-types
library[2]. A Name is the name of an XML element or attribute.
That instance calls error when the string contains a certain kind of invalid domain-specific syntax. Some are even advocating expanding this behavior to any string that is syntactically invalid for XML names.
So we now have GHC as the only major compiler which can cause *runtime* crashes depending on what characters are used in a string literal.
OverloadedStrings as a more general mechanism is very
convenient in many settings. One of them is XML names;
another is attoparsec-text[3] parsers. I must
admit I have succumbed to the temptation of making this
deal with the devil and benefiting from them.
But when used this way OverloadedStrings
is really just another syntax for quasi-quotation, and that
is what should have been used explicitly instead of these
unsafe domain-specific IsString instances.
I propose fixing the problem in one of the following ways:
A. Make string literals syntax in fact a specialized
quasi-quotation when OverloadedStrings is turned on. That way, exceptions are caught at compile time as they should be.
B. Bless Text, and possibly ByteString, as the only types that
get magical behavior of string literals.
C. Remove OverloadedStrings altogether.
Option A is by far the nicest. But it requires GHC
to know the type of the string literal before
the cast is applied. We might also need some way to help
GHC find the cast function at the right time, beyond just
having an IsString instance somewhere in scope.
By submitting this bug, I am making it clear that I am opposed
to Option D, leaving things the way they are and wishing
everyone the best of luck. The OverloadedStrings pragma
is not really optional anymore now that Text is becoming
the default string type in practice for Haskell. It is not
acceptable to have to wrap every string awkwardly with
(T.pack "") and give up the chance of it being CAFfed.
In fact, the blaze-html[4] library relies on
OverloadedStrings for its performance[5].
I am also opposed, though less so, to providing a deprecation route by using a new language pragma for Option A or B. The current behavior is dangerous and should be summarily removed.