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

[Gabriel Gonzalez]

> 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.

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.