[Haskell-cafe] Call for discussion: OverloadedLists extension
apfelmus at quantentunnel.de
Sun Sep 23 10:51:26 CEST 2012
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
The core point of the OverloadedSomething extensions is that they
address a syntactic issue, namely that we can write
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
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.
More information about the Haskell-Cafe