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