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

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 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. On Sun, Jul 14, 2013 at 10:43 PM, Edward Kmett wrote:

I was at first against this proposal by a knee jerk "but it isn't a string" response.

But now, after considering it, I'm (mildly) in favor of this proposal just because a.) it only affects you once you've turned on OverloadedStrings which serves as a clear indication that hinky stuff might be going on, and b.) it is the only place such an instance could live that isn't an orphan and c.) it is the least prescriptive option. Very few of the users in the more prescriptivist camp are using OverloadedStrings to begin with. ;)

The proposed laws for how fromString and Monoid should relate largely ignore the existing usecases people have for tokenizing parsers and embedding string literals in ASTs -- which as I recall was a decent part of why Lennart originally put fromString forward, so I'm not sure I can concede the moral high ground to those citing the fact that we might want to put laws on the class. It might have been nice to put some laws in place about the class, but the laws that have been put forth largely ignore how this language extension gets used in practice.

-Edward

On Sun, Jul 14, 2013 at 9:40 PM, Conrad Parker wrote:

...

On 10 July 2013 05:24, Simon Hengel wrote:

...

Hi, what about adding

instance IsString a => IsString (Maybe a) where fromString = Just . fromString

It makes specifying optional String/Text/... values more convenient. Here is an example that uses System.Process.shell:

Use

shell "ls -l" { cwd = "/home/me" }

instead of

shell "ls -l" { cwd = Just "/home/me" }

I'm not yet sure how essential it is. But I somehow can't see any issues with it. So why not?

+1

After reviewing the resulting discussion I agree that there's no possible ambiguity and Simon's use-case is compelling. I think it's great that this allows us to write obvious code without cluttering the common use-case with Justs, while still allowing the underlying types to be properly expressive (ie. admitting a Nothing value when that is appropriate). This is especially important for a DSL that uses lots of strings, like shell scripting.

I think (Maybe String) is a perfectly good string; it's just a string type that has an extra value of Nothing -- and Nothing doesn't even play a part in the IsString instance.

Conrad.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries