Proposal: Add IsString instance for (Maybe a) to base

John Lato jwlato at
Fri Jul 12 07:56:31 CEST 2013

On Fri, Jul 12, 2013 at 12:57 PM, Gabriel Gonzalez <gabriel439 at>wrote:

> To play devil's advocate, why?
>> What does limiting IsString in this fashion gain anyone?  It doesn't
>> complicate type inference any more than it already is.  For any
>> applicative, there's the trivial instance
>> instance (IsString a, Applicative t) =>  IsString (t a) where
>>      fromString = pure . fromString
>> which is conceptually a very simple step and is always total.
>> Of course some functors admit other instances.  I think some parser
>> libraries already provide IsString instances as a nice syntax on matching
>> string literals.  A rule like this would invalidate those instances for no
>> particularly good reason I can see.
> There is a tension between the "Do what I say" approach to library design
> and the "Do what I mean" approach where the library guesses at the
> programmer's intention and tries to succeed at all cost, sometimes failing
> silently when it guesses wrong.  The Haskell development philosophy seems
> to err on the side of avoiding mistakes, which leads me to favor asking the
> programmer to be explicit in this particular case and not auto-inserting
> `Just`s for them.

The programmer is being explicit; the type specifies the value is a Maybe.
 If it weren't, the Just wouldn't be inserted.

Can you provide an example of code that compiles with this instance and
does the wrong thing?  I'm afraid I don't see a conflict between DWIS/DWIM
here, as I cannot envision any situation where this would "guess wrong".  I
also cannot comprehend code where this instance would ever do anything
other than "what I say".

I can see a case where a user may be requested to supply an additional type
annotation, however that's already true.

Also, scope creep for type classes like `IsString` makes it more difficult
> to reason about what their methods mean.  These more exotic `IsString`
> instances dilute the meaning and precision of the original type class.
>  When I wrote a string in a program with `OverloadedStrings` enabled, the
> meaning used to be: "This is text".  Then the meaning became: "This uses
> text internally, somewhere."  As time goes on, I expect the meaning will
> eventually become: "This is convenient", whatever that means.

I prefer to think of the meaning as "a mapping from string literals into
the instance type."  This quite closely with both the use of
OverloadedStrings and the type of fromString.  It's also perfectly
compatible with a more general notion of IsString as proposed.  What you
consider scope creep is simply an artificial restriction of a more general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list