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

[John Lato]

On Fri, Jul 12, 2013 at 3:57 PM, Evan Laforge <qdunkan at gmail.com> wrote:

> On Fri, Jul 12, 2013 at 2:45 AM, John Lato <jwlato at gmail.com> wrote:
> > On Fri, Jul 12, 2013 at 2:13 PM, Roman Cheplyaka <roma at ro-che.info>
> wrote:
> >>
> >> * John Lato <jwlato at gmail.com> [2013-07-12 13:56:31+0800]
> >> > The programmer is being explicit; the type specifies the value is a
> >> > Maybe.
> >> >  If it weren't, the Just wouldn't be inserted.
> >>
> >> Not necessarily — take Simon's original example:
> >>
> >>   (shell "ls -l") { cwd = "/home/me" }
> >>
> >> If I didn't know the type of 'cwd', it would never occur to me while
> >> reading this code that you can supply Nothing there.
> >
> > So?  If you're just reading the code, it doesn't matter.  If you want to
>
> It does to me!  Concrete types help me read.  I have a lot of trouble
> understanding libraries that make extensive use of typeclasses, both
> reading their documentation and reading code that uses them.
>

I agree completely, but it's already typeclass-based as soon as you enable
OverloadedStrings.  If you want concrete types, just don't use
OverloadedStrings and you'll be good.


>
> > OverloadedStrings (and number literals) are already a mess for this.
> > Currently, we have
> >
> >     (shell "ls -l") { cwd = Just "/home/me" }
> >
> > If I want to replace that literal with a value and I don't know the type
> of
> > 'cwd', I already need to look it up.  Otherwise I might try to do
> something
> > like this:
> >
> >     dirFromUser <- Text.getLine
> >     (shell "ls -l") { cwd = Just dirFromUser }
>
> I probably wouldn't, because I know the process package uses Strings.


In all seriousness, I'm not that fond of the proposal myself.  I just
wanted to argue the other side because nobody else was.  But so far, I've
seen two main arguments against the proposal:

1.  IsString is for things that are notionally some sort of string.
2.  It makes the types more confusing.

The second seems like a weak argument to me.  First off, the proposal seems
very similar to the recent generalization of Prelude.map, which had a great
deal of support.  Secondly, this objection appears to posit a programmer
who knows the types well enough to differentiate between
String/Text/ByteString, but not well enough to differentiate String/Maybe
String.  Which I suppose may be the case.  It's easier to remember "package
X uses Strings" than having to remember "X.foo :: String, X.bar :: Maybe
String" etc.  But I end up looking up the types of things quite frequently
already, and I don't believe that this addition would have a very large
impact on the number of type lookups I perform.

I find the first argument more convincing, but I'm starting to think it's
nothing more than a self-imposed limitation.  Right now, most people seem
to think IsString should mean "this data is notionally a string".  I think
that even Maybe String/Text fits that definition.  But it seems even better
to give IsString the meaning "string literals represent values of this
type".  It's both closer to how OverloadedStrings interprets IsString
instances and more general.  With this meaning, the slippery slope to other
applicatives isn't a slope at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130712/acae1883/attachment-0001.htm>