On Sun, Sep 23, 2012 at 10:51 AM, Heinrich Apfelmus
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@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