Proposal: Improving the IsString String instance

Dan Burton at
Mon Aug 26 22:09:00 CEST 2013

Just to throw another curveball at this conversation, what about a general,
ad-hoc solution for 'typeclass defaults'? The logic goes like this: Is
there an "ambiguous type variable" error due to the use of the IsString
typeclass? Try defaulting to the String instance. If that doesn't work, try
defaulting to Text. Repeat for a finite, explicit list of instances. If
none of these defaults are successful, type error.

We have hard-coded this sort of behavior into the Num class. Why not just
provide this general capability for arbitrary classes? Or at least
hard-code it into IsString as well.

In the absence of this sort of solution, +1 to Edward's original proposal.

The "o" proposal is not viable because the oft-needed parens make it
confusing and irritating to the new Haskeller.

-- Dan Burton

On Mon, Aug 26, 2013 at 12:41 PM, Henning Thielemann <
lemming at> wrote:

> On Mon, 26 Aug 2013, Gabriel Gonzalez wrote:
>  I'm guessing this is sarcastic, but I just want to clarify what I
>> understood Henning's proposal to be.  He's not saying we should provide an
>> `o` function in the standard library, but rather encourage users to define
>> their own.
> Yes. I would be ok if packages provide this function, but I would urge
> programmers to import that explicitly.
>   This one liner would take the place of the current line that they devote
>> right now to `OverloadedStrings` .
> right
>  However, the analogy is still apt since the exact same line of reasoning
>> applies to overloaded numeric
>> literals where we currently rely on defaulting to solve this problem.
> I always use -Wall and thus I am warned about when defaulting takes place.
> Thus I am confident that I do not rely on defaulting in my code.
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list