Proposal: Improving the IsString String instance

Edward Kmett ekmett at
Mon Aug 26 18:45:31 CEST 2013

If Ian can make defaulting work, then I'd prefer that solution. It hurts
nobody and just makes everything work better.

length was just the most galling example among many.

The resolution to Ian's suggestion would absolutely affect just how liberal
we want to be with generalizing more of the list combinators to

There are a lot of desiderata to consider in balancing the needs of base.

Forcing the only list based instance to be String is an arbitrary decision,
but it fixes the vast majority of the issues with a typeclass and extension
that was intended to be a convenience but currently causes a great deal of
incovenience in otherwise unrelated code when you turn it on.

Having base export two randomly different versions of the same combinator
all over the place is also an inconvenience and fixing it comes with some
tension towards OverloadedStrings.

Forcing users to use signatures on every String and import Data.Traversableand
Data.Foldable qualified "works," but it is the design equivalent of
sticking your head in the sand and pretending their we don't have any


On Mon, Aug 26, 2013 at 12:33 PM, Henning Thielemann <
schlepptop at> wrote:

> Am 25.08.2013 23:02, schrieb Edward Kmett:
>  The issue is that length "abc", splitAt 2 "abc", and dozens of other
>> tools just stop working for anyone who turns on OverloadedStrings right
>> now.
>> IsString was originally put forth as a convenience to make string
>> literals work with Text, ByteString, directly as a parsing combinator,
>> or as a variable name or string type in an expression language, but
>> presently that functionality comes at the tax that random other bits of
>> code in your file stop working when you turn it on.
>> My proposal is intended to address this fact, by giving up a subset of
>> possible convenience instances in exchange for fixing the real headache
>> this induces for users.
> What you propose is, to let the compiler infer: "If it is something
> string-like (imposed by the string literal syntax in the presence of
> OverloadedStrings) and it is a list (imposed by 'length'), then it must be
> a String".
> This conclusion looks rather arbitrary to me. If 'length' would be more
> specific (e.g. Text.length) your problem would not arise. If 'length' would
> be more generic (e.g. Foldable.length) your proposal would not help. The
> problem only arises, because you want to use Prelude's list functions
> (_and_ OverloadedStrings _and_ don't want to write type annotations).
> I predict that soon people will propose here on this mailing list to
> replace Prelude's half-monomorphic 'length' by a fully polymorphic
> Foldable.length. It does not yet exist, but it could be added easily. What
> will you do then?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list