On Thu, Jan 9, 2014 at 5:29 PM, Artyom Kazak <yom@artyom.me> wrote:

On 01/10/2014 04:17 AM, John Lato wrote:

I think this is a really important point. If I may go further, it's arguable that 'type String = [Char]' was a poor decision, and one of the arguments is that it's not possible to make different instances for String and [a] (hence the showsList issue).

Actually, I think it’s an instance of a bigger problem: *newtypes aren’t as transparent as they should’ve been*. The very first thing a beginner is told about newtypes is that they bear no additional runtime cost at all – which, in fact, hasn’t been strictly true until the recent introduction of Roles – but the first thing they learn *by theirself* is that newtypes are only “free” for the computer, not for the programmer!

Imagine an alternative Prelude in which `String` is a newtype for `[Char]` and not a type synonym: you wouldn’t be able to `map` over it without deconstructing it first, or `reverse` it, or even compute its `length`... And having to type `f (Str s)` instead of `f s` would already discourage people enough that most of them would be trying to avoid Strings, even if only subconsciously.

General tendency to follow the path of least resistance is probably the reason why newtypes aren’t used as often as they should be. Have there been any proposals aiming to solve this issue? (A quick search didn’t bring up anything, but maybe I was just searching for a wrong thing.)

The programmer overhead from newtypes is greater than I would like, even as minimal as it is.

I find that using isomorphisms from the lens package goes a long way to reducing the programmer overhead from using newtypes. I recently did a very lens-heavy project, and I found that the ease of working with newtype'd values via isomorphisms made me much more likely to define newtypes in the first place. So that's one solution, YMMV.

Of course, that's assuming that String would just be a newtype instead of a type alias. If it were an actual abstract type, then we couldn't use map/fmap at all. However, we've had type class based solutions for that problem for some time now, e.g. the ListLike package, and newer alternatives like mono-traversable. (Incidentally, I've been toying with the idea of making ListLike depend on mono-traversable. It would basically just be an API re-skinning, plus we could have more efficient definitions of some functions).

An abstract String would also be better than our current situation because Data.List functions on Strings are just plain wrong anyway. Simple example: what should be the reverse of "This is two lines\r\nbecause Windows!\r\n"? It gets even more fun with unicode. Oddly, I was just looking at http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg-ponies-aka-humanity-epic-fail.aspx 10 minutes ago.

(Of course if String were properly abstract, you could still define an isomorphism between String and [Char] somehow. And somewhere in Turkey a tier-1 techie cries out...)