[Haskell-cafe] Call for discussion: OverloadedLists extension

[Michael Snoyman]

On Sun, Sep 23, 2012 at 10:51 AM, Heinrich Apfelmus
<apfelmus at quantentunnel.de> wrote:
> Michael Snoyman wrote:
>>
>> (Prettier formatting available at: https://gist.github.com/3761252)
>>
>> Many of us use the OverloadedStrings language extension on a regular
>> basis. It provides the ability to keep the ease-of-use of string
>> literal syntax, while getting the performance and correctness
>> advantages of specialized datatypes like ByteString and Text. I think
>> we can get the same kind of benefit by allowing another literal syntax
>> to be overloaded, namely lists.
>
>
> Actually, I am already somewhat reserved about the  OverloadedStrings
> proposal.
>
> The core point of the OverloadedSomething extensions is that they address a
> syntactic issue, namely that we can write
>
>   "example"
>
> instead of
>
>   (pack "example")
>
> The extension does this by making the literal polymorphic.
>
> Unfortunately, making literals polymorphic does not always achieve the
> desired effect of reducing syntax. In fact, they can instead increase
> syntax! In other words, I would like to point out that there is a trade-off
> involved: is it worth introducing a small syntactic reduction at the cost of
> both a small additional conceptual complexity and some syntactic enlargement
> elsewhere?
>
>
> The increase in syntax happened to me while using one of the json libraries.
> The thing is that if a "receiver" function is agnostic in the string used,
> or if it is otherwise polymorphic,
>
>     receive1 :: IsString s => s -> Foo
>     receive2 :: JSON s => s -> Foo
>
> then I have to specify the type of the overloaded argument (either by a type
> annotation or a monomorphic function call).
>
> In other words, without  OverloadedStrings , I was able to write
>
>     receive2 "example"
>
> but with the extension, I now have to write
>
>     receive2 (pack "example")
>
>
> A similar effect can be seen with the good old numeric literals. Sometimes,
> you just have to introduce a type signature (:: Int) to make a program
> unambiguous.
>
>
> In this light, I don't think that the trade-off made by the OverloadedLists
> extension is big enough.
>
>
> Best regards,
> Heinrich Apfelmus
>
> --
> http://apfelmus.nfshost.com
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

I agree with your point. But what you've pointed out is that there's a
trade-off involved, and then elaborated on the downsides of the
trade-off. Let's not forget that there are significant upsides as
well. And based on the large amount of code out there that actually
uses OverloadedStrings, I think many people feel that the upsides
outweigh the downsides in many cases. The nice thing about an
extension like OverloadedStrings or OverloadedLists is that it need
not affect your code in any way: if you don't turn it on, your code
will continue to work. And you'll still be able to use libraries that
themselves use the extensions without any ill effects.

That said, it would be great to come up with ways to mitigate the
downsides of unbounded polymorphism that you bring up. One idea I've
seen mentioned before is to modify these extension so that they target
a specific instance of IsString/IsList, e.g.:

{-# STRING_LITERALS_AS Text #-}

"foo" ==> (fromString "foo" :: Text)

Another might be more intelligent/powerful defaulting rules, similar
to what we have already with numeric literal overloading.

Michael