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

[MightyByte]

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 at 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 at metadecks.org>wrote:
>
>> On 10 July 2013 05:24, Simon Hengel <sol at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130715/7b74b764/attachment.htm>