
On Tue, Jul 16, 2013 at 1:53 AM, Roman Cheplyaka
I'll just throw out a data point related to this discussion. In one of my previous commercial Haskell projects we ended up writing a similar Num instance for Maybe a. I think I asked about it in #haskell back then and got pretty vocal distaste about the idea from several people who spoke up. "Maybe is not a number!" But we did end up using the instance in our project because it greatly simplified a section of our code. I'm certainly not going to recommend that we also add the Num instance for Maybe. But I think it's a useful data point that this happened in real-world
* MightyByte
[2013-07-15 08:26:13-0400] production code at a company where writing Haskell code was my full-time job.
As for my personal opinion on this proposal, I'm on the fence. I can see how it would be nice to have this kind of convenience, but the arguments on the opposing side also resonate with me as well.
I don't see any contradiction here.
It's perfectly fine if you decided that you need that instance and introduced it in your code. It would be very strange if someone said you shouldn't do that.
I also don't mind package authors (ab)using IsString to make their libraries more convenient to use. If someone doesn't like that library, they doesn't have to use it.
What I am against is putting that instance into base, thus making it impossible to opt-out.
It's opt-in, not opt-out. You opt-in by turning on OverloadedStrings. If you don't want your strings to be other than Strings, don't enable the extension. I get the sense that a lot of people feel OverloadedStrings really means ProperStringLiterals, and want to use the extension as a proxy for a language with String type that isn't [Char]. I don't think it's correct to co-opt a generalizing extension to try to cover up a prior issue with the language. We probably should add a ProperStringLiterals extension, actually.