[Haskell-cafe] Why Maybe exists if there is Either?

[John Lato]

On Thu, Jan 9, 2014 at 5:29 PM, Artyom Kazak <yom at 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...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140109/b1ce72e7/attachment.html>