#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
---------------------------------+------------------------------------------
Comment(by jmillikin):
I'm the author of the xml-types in question. The {{{IsString}}} instance
was added at the request of Michael Snoyman, who wanted a syntactically-
easy way to define element names. I agree with him that it is useful, but
feel it should be regarded as trivial syntactic sugar in the vein of
{{{Data.ByteString.Char8}}}.
It would be very useful for the compiler to support some kind of string
literal validation, since there are currently several ways that bad
literals can cause unexpected runtime failure:
1) ByteString literals can be constructed with characters where {{{ord(c)
> 255}}}
2) Text literals can be constructed with characters that are not valid
Unicode.
3) {{{Int}}}, {{{Word}}}, and their variants can be constructed from
literals that exceed their bounds.
IMO, at minimum throwing a runtime exception for these cases would be
better than the current behavior, which is to return some arbitrary
garbage value. Failing loudly and obviously saves much debugging time when
the value is subtly wrong.
Using quasi-quoters are not a good solution, as they drag in the whole
horrific mess that is Template Haskell. They're also not much better than
simply using existing constructors:
{{{
-- I like this style
name :: Text -> Text -> Name
name namespace local = Name local (Just namespace) Nothing
someName :: Name
someName = name "foo" "bar"
-- The current IsString enables this style
someName :: Name
someName = "{foo}bar"
-- A quasi-quoter would look something like this, at best
someName :: Name
someName = $(qqName "{foo}bar")
}}}
(side note: Calling this a "crash" is silly, since nothing crashes, and
the error is reported as a standard exception. The word "crash" should be
reserved for actual crashes, such as {{{peek nullPtr}}}).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5255#comment:6>
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
