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 <ekmett@gmail.com> 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 <conrad@metadecks.org> wrote:
On 10 July 2013 05:24, Simon Hengel <sol@typeful.net> 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