#5255: String literals cause runtime crashes when OverloadedStrings is in effect
---------------------------------+------------------------------------------
Reporter: YitzGale | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.0.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Description changed by simonpj:
Old description:
> 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.
>
> * [1] http://www.haskell.org/pipermail/web-devel/2011/001630.html
> * [2] http://hackage.haskell.org/package/xml-types
> * [3] http://hackage.haskell.org/package/attoparsec-text
> * [4] http://hackage.haskell.org/package/blaze-html
> * [5] http://www.haskell.org/pipermail/web-devel/2011/001717.html
New description:
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.
* [1] http://www.haskell.org/pipermail/web-devel/2011/001630.html
* [2] http://hackage.haskell.org/package/xml-types
* [3] http://hackage.haskell.org/package/attoparsec-text
* [4] http://hackage.haskell.org/package/blaze-html
* [5] http://www.haskell.org/pipermail/web-devel/2011/001717.html
--
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5255#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
