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

On Fri, Jul 12, 2013 at 2:45 AM, John Lato <jwlato@gmail.com> wrote:
> On Fri, Jul 12, 2013 at 2:13 PM, Roman Cheplyaka <roma@ro-che.info> wrote:
>>
>> * John Lato <jwlato@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.