4 ms·
As a non-fan of OverloadedStrings, I'm not sure how I feel about this.
by IsTom 13y ago
As a non-fan of OverloadedStrings, I'm not sure how I feel about this.
- dllthomas 13y agoWhat are your objections to OverloadedStrings?
- chongli 13y agoIt can give unexpected/wrong results when working with Unicode strings.
- dllthomas 13y agoA reasonable objection, but I don't see that it applies to OverloadedLists either directly or by analogy (though I could totally be missing something).
- hesselink 13y agoCan you elaborate? Perhaps you are talking about the Char8 ByteString instance? It was a mistake to declare that instance, I think.
- chongli 13y agoPerhaps 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 $ "Российская Федерация" Российская Федерация
- startling 13y agoThat's an issue with Data.ByteString.Char8, not with OverloadedStrings.
- chongli 13y agoWhen 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.
- tel 13y agoI 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.
- chongli 13y agoAhh, 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!
- tel 13y agoTotally agree that it's a weak class. I'd love it if `IsList` were a subclass of `Foldable`!
- tel 13y agoThat'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]
- IsTom 13y agoIt 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.
- dllthomas 13y agoThat's pretty reasonable, yeah.
- tel 13y agoI 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.
- Kutta 13y agoI 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.