#5255: String literals cause runtime crashes when OverloadedStrings is in effect
---------------------------------+------------------------------------------
    Reporter:  YitzGale          |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  Compiler    
     Version:  7.0.3             |    Keywords:              
    Testcase:                    |   Blockedby:              
          Os:  Unknown/Multiple  |    Blocking:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
 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>
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

Reply via email to