Comment by applicative | Hacker News Reader

Comment by applicative | Hacker News Reader

Parent Full thread

Of course we know what defaulting is. Why is it bad? I don't think I myself would even notice if it weren't there, since I write type signatures before I write the value expressions for them. I guess it is convenient if you are noodling around in ghci. With -XOverloadedStrings you get the same effect:

    ghci -XOverloadedStrings
    Prelude> :m +Data.Text
    Prelude Data.Text> "cargo cult"
    "cargo cult"
    Prelude Data.Text> :t it
    it :: String
    Prelude Data.Text> "cargo cult" :: Text
    "cargo cult"
    Prelude Data.Text> :t it
    it :: Text

It defaults to String. What's wrong with this exactly? A general coercion, understood as something different from a function (pack, unpack), would have to coerce between two types of wildly different structures. One is a list type [Char] that you can map over and into from any kind of list you like - and the user is forever employing this fact - the other is totally different.

It is different from other systems, but doesn't that just mean you have to learn something different, which is of course annoying until it becomes second nature. There doesn't seem to be any legitimate technical objection here, or am I wrong?

Of course we know what defaulting is. Why is it bad?

I wonder who is that we you refer to. Is applicative a Bourbaki-style pseudonym for a group of aspiring Haskell hackers?

I never said it is bad, it looks like a useful and convenient mechanism. My complaint is about its non-genericity. Indeed, it is limited to numeric literals only; even to reuse it for string literals, you need a compiler extension.

A general coercion, understood as something different from a function (pack, unpack), would have to coerce between two types of wildly different structures.

By general coercion, I mean implicit conversion not limited to numeric literals (or string literals, with an extension) only.

By "we" I meant reikonomusha and myself, as the context made plain. I don't see how calling something an ugly hack isn't a form of calling it bad, but never mind.

Numeric and string literals are all that were ever under discussion. `OverloadedStrings` is a language extension, not a compiler extension; it is a candidate for inclusion in later specifications, not in the new Haskell 2010. The Ghc supports it with a language pragma. That it, and the associated IsString class, didn't exist in Haskell 98, the previous specification, is obviously due to the fact that there was not widespread use of types like ByteString and Text for handling text; if there had been it would have been, surely; the idea is pretty straightforward.

Reply on news.ycombinator.com