Hacker News Reader

Comment by IsTom | Hacker News Reader

As a non-fan of OverloadedStrings, I'm not sure how I feel about this.

I think OverloadedStrings makes things more ambiguous. It's a power-feature, to be sure, but it also makes the use of Text and ByteString much more available in much the same way that numeric literals do (literally the same way, actually).

I think that sort of ambiguity is part of Haskell. It rescinds a bit on the HM promise of never having to write types, but Haskell has long rescinded on that in spirit and practice. It leads to a bit of beginner trouble, but, again, not any more than numeric literals do.

I welcome overloaded lists because I feel it'll make more libraries willing to expose Set-typed interfaces when that's the honest contract that should be upheld by the interface. That's what I want my types to tell me—not just what's syntactically convenient.

I somewhat agree on the last point. The temptation is often too great to use those horrible, horrible O(n^2) set functions (nub, difference, intersection) from Data.List just because of the immediate availability.

What are your objections to OverloadedStrings?

It can give unexpected/wrong results when working with Unicode strings.

A reasonable objection, but I don't see that it applies to OverloadedLists either directly or by analogy (though I could totally be missing something).

Can you elaborate? Perhaps you are talking about the Char8 ByteString instance? It was a mistake to declare that instance, I think.

Perhaps you are talking about the Char8 ByteString instance?

Yes. Data.ByteString.Char8.pack does not form an isomorphism with Data.ByteString.Char8.unpack. It is thus not interchangeable with String.

Example:

    Prelude Data.ByteString.Char8> putStrLn . unpack . pack $ "Российская Федерация"
    >AA89A:0O $545@0F8O

And here the correct result with Data.Text:

    Prelude Data.Text> putStrLn . unpack . pack $ "Российская Федерация"
    Российская Федерация

That's an issue with Data.ByteString.Char8, not with OverloadedStrings.

When you use OverloadedStrings in conjunction with Data.ByteString.Char8 it becomes OverloadedStrings' issue as well. Compile-time transformations are not supposed to break your program.

I don't think of it as a compile-time transformation but instead a weakening of the semantics of string literals. Without we have

    "foo" :: String

and with we have

    "foo" :: IsString a => a

much like

    3 :: Num a => a

It inherits all of the same weaknesses and strengths that we have with the Num typeclass.

Ahh, very good. Then perhaps our target of inquiry ought to be the IsString class. Ought it have some laws we can expect instances to follow, akin to the Monad laws? At the moment, we can write:

    instance IsString () where
    fromString = const ()

And there's nothing wrong with it!

Totally agree that it's a weak class. I'd love it if `IsList` were a subclass of `Foldable`!

That's true. Similarly, I expect that for types with weird Eq or Ord instances overloaded lists might give strange results. That said, those issues still exist when someone types

    pack "<unicode> string"
    fromList [1,2,3,4,4.000000000000000000000000001]

It just makes programs ambigious when reading. The amount of typing you save is the amount of type information the reader loses. It's okay if there's just one instance of IsString you're actually using, but if you're using few of them in the same module it turns out to not be satisfactory for my tastes.

That's pretty reasonable, yeah.

Reply on news.ycombinator.com