Hi Johannes, I thought there was some "more important" reason than convenience, so I asked. :-O) I put String because I'm currently thinking about error handling, and Left String is the usual way of reporting failure, and I see Maybe as a type for reporting errors, failures and similar. Somehow it looks to me that famous "8 ways to report errors in Haskell" could be shortened by one if Maybe is replaced with Either (with appropriate synonyms, of course). vlatko -------- Original Message -------- Subject: Re: [Haskell-cafe] Why Maybe exists if there is Either? From: Johannes Erber To: vlatko.basic@gmail.com, haskell-cafe@haskell.org Date: 09.01.2014 16:07

Hi Vlatko,

to keep programs clear, short and simple. What makes you choose String as type to replace Nothing?

Best, Johannes

On 09/01/2014 14:50, Vlatko Basic wrote:

...

Hello Cafe,

With my current knowledge of Haskell, I do not see why is there Maybe if we have Either.

For example, Functor and Monad instances (and many others) of Maybe and Either are the same (except for fail).

In other words, this should hold:

Maybe a = Either String a -- String or something else Nothing = Left "" Just a = Right a

I'm curious to find out what was the reasoning to make Maybe? What is the added value with introducing it? In which situations the above substitution does not hold?

Best regards,

vlatko

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Thu, Jan 9, 2014 at 12:12 PM, Brandon Allbery wrote:

On Thu, Jan 9, 2014 at 11:52 AM, Vlatko Basic wrote:

...

...

... what exactly is the problem with using appropriate data types in appropriate places ... It is a good thing. Very good. But I do not think all library writers are using it in correct places. But that's another problem.

In Haskell it's even a solved one: use an appropriate typeclass. We have several error-like typeclasses. Admittedly, if some library does not take advantage of this your recourse may be to submit a patch.

And you still seem to be fixated on the notion that Maybe is only for errors. What exactly is the error in "user did not provide an optional parameter"?

Indeed. I use Maybe for non-errors, namely optional values, all the time. To compare with some other languages: Maybe is like a nil vs. non-nil pointer. Either is like returning two values/a tuple of Foo and Error. (For that matter, I sometimes use Either when a value can be either something or the other, but neither of them are errors.)

Hi Vlatko, it is not only about convenience, but also about readability and conciseness which are quite important in order to maintain software and to prevent it from getting cluttered up unnecessarily. Also Maybe evolves naturally as minimal complete type for use cases in which you can have either a value or no value. Either extends Maybe by more information why no value is returned by a function. Of course you could replace Maybe with Eithers and your code would still work, but it would be much less concise and hence maintainable. Best, Johannes On 09/01/2014 15:26, Vlatko Basic wrote:

Hi Johannes,

I thought there was some "more important" reason than convenience, so I asked. :-O)

I put String because I'm currently thinking about error handling, and Left String is the usual way of reporting failure, and I see Maybe as a type for reporting errors, failures and similar.

Somehow it looks to me that famous "8 ways to report errors in Haskell" could be shortened by one if Maybe is replaced with Either (with appropriate synonyms, of course).

vlatko

-------- Original Message -------- Subject: Re: [Haskell-cafe] Why Maybe exists if there is Either? From: Johannes Erber To: vlatko.basic@gmail.com, haskell-cafe@haskell.org Date: 09.01.2014 16:07

...

Hi Vlatko,

to keep programs clear, short and simple. What makes you choose String as type to replace Nothing?

Best, Johannes

On 09/01/2014 14:50, Vlatko Basic wrote:

...

Hello Cafe,

With my current knowledge of Haskell, I do not see why is there Maybe if we have Either.

For example, Functor and Monad instances (and many others) of Maybe and Either are the same (except for fail).

In other words, this should hold:

Maybe a = Either String a -- String or something else Nothing = Left "" Just a = Right a

I'm curious to find out what was the reasoning to make Maybe? What is the added value with introducing it? In which situations the above substitution does not hold?

Best regards,

vlatko

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Thu, Jan 9, 2014 at 10:36 AM, Vlatko Basic wrote:

...

If you just want to signalize a fail case without any additional information, then a Maybe fits better than an Either, because why should you need this bogus empty string?

Now it looks to me that it might be better and more consistent to write an empty bogus string (as with: nothing = Left "") than to have two distinct ways of error reporting, and both are used widely and often should be intermixed. And at the end, call site could decide does it want to use the string or not.

I should note here that this is pretty much the "fail" method for Monad, which is widely considered to have been a mistake. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Hi Artyom, Yes, indeed. But instance declarations wouldn't be needed because we already have all the instances for Either. The point would be to have them unified. But it is a problem that there are no data constructor synonyms in Haskell. So at least pattern matching wouldn't be possible the simple way. Maybe ViewPatterns could (partially) solve that. vlatko -------- Original Message -------- Subject: Re: [Haskell-cafe] Why Maybe exists if there is Either? From: Artyom Kazak To: haskell-cafe@haskell.org Date: 09.01.2014 16:23

Besides, even defining

type Maybe a = Either () a

in standard library wouldn’t be the same as

data Maybe a = Nothing | Just a

since in Haskell 98 type synonyms aren’t allowed in instance declarations, which means that programmers would still have to remember that `Maybe` is actually `Either ()` under-the-hood every time when writing an instance. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

But you actually might want different instances for `Maybe` and for `Either`. For example, let's say that you have a typeclasse for serializing data-structures into a database. In case of Maybe you want to serialize `Nothing` into 'NULL' or something similar; in case of Either you want to have an entirely different structure. Additionally, as it have been mentioned, `Either String a` is not the same thing as `Maybe a`. Say, you have a value of type `Either String a`. How do you know that all `Left`-values are suppose to be empty string? What do you actually want is `Either () a`. On Thu, Jan 9, 2014 at 8:36 PM, Vlatko Basic wrote:

Hi Artyom,

Yes, indeed.

But instance declarations wouldn't be needed because we already have all the instances for Either. The point would be to have them unified. But it is a problem that there are no data constructor synonyms in Haskell. So at least pattern matching wouldn't be possible the simple way. Maybe ViewPatterns could (partially) solve that.

vlatko

-------- Original Message -------- Subject: Re: [Haskell-cafe] Why Maybe exists if there is Either? From: Artyom Kazak To: haskell-cafe@haskell.org Date: 09.01.2014 16:23

...

Besides, even defining

type Maybe a = Either () a

in standard library wouldn’t be the same as

data Maybe a = Nothing | Just a

since in Haskell 98 type synonyms aren’t allowed in instance declarations, which means that programmers would still have to remember that `Maybe` is actually `Either ()` under-the-hood every time when writing an instance. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Sincerely yours, -- Daniil

On Thu, Jan 9, 2014 at 8:51 AM, Artyom Kazak wrote:

On 01/09/2014 08:36 PM, Vlatko Basic wrote:

...

But instance declarations wouldn't be needed because we already have all the instances for Either. The point would be to have them unified.

Consider a generic Show instance for Either – there’s no way¹ to make it behave differently for Either () (or Maybe if it was a type synonym). I think there are other cases in which we want Maybe to behave differently from Either, but I can’t think of any on the spot.

¹ this point also applies to String, which is a type synonym for [Char] – and it was solved somewhat inelegantly by adding an additional method to Show typeclass *specifically* for showing lists of things.

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). Also, due to laziness, Either () a is bigger than Maybe a. It should be 'Either Void a'. But Void has only recently been added to the standard-ish library, which means if we'd used Either () from the start now we'd be stuck with the wrong type. I'd rather have a separate Maybe that does exactly what it's meant to. John L.

On Thu, Jan 9, 2014 at 5:29 PM, Artyom Kazak 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... 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...)

Hi, Am Mittwoch, den 22.01.2014, 14:56 +1300 schrieb Richard A. O'Keefe:

If there is _any_ sane way to reverse a Unicode string, which I rather doubt, it would be _horrible_ to implement it.

I suggest this:

reverse unicode_str = '\u202E' : unicode_str

‮It works great! Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

Hi, Am Mittwoch, den 22.01.2014, 14:04 +0400 schrieb Daniil Frumin:

Ha, this is a clever trick. Does it really work in all the cases?

that depends on the unicode implementation of the client, of course. But in enough cases to annoy or confuse people. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

On 22/01/2014, at 10:23 PM, Joachim Breitner wrote:

Am Mittwoch, den 22.01.2014, 14:56 +1300 schrieb Richard A. O'Keefe:

...

If there is _any_ sane way to reverse a Unicode string, which I rather doubt, it would be _horrible_ to implement it.

I suggest this:

...

reverse unicode_str = '\u202E' : unicode_str

‮It works great!

According to "Unicode Demystified", The Unicode bidirectional text layout algorithm (or "bi-di algorithm," as it is most commonly called) is possibly the most complicated and difficult-to- understand aspect of the Unicode standard. Considering the rest of Unicode, that says a LOT. This particular example using RIGHT-TO-LEFT OVERRIDE is a neat hack, but as a *general* way to reverse strings it's a FAIL: let s="\u202DIt's harder than you think." '\u202E' : s You will see no reversal in the output. Reverting to the original topic, Maybe and Either signify different things to human beings, and in the original libraries, the cost of having both was negligible compared with the benefits. Just recently I was revising some code in another language, where they had the equivalent of infinity = 99999.0 to serve as the initial value in a "search for the cheapest element and its cost" loop, and I suggested the equivalent of using Maybe (Cost, Item) instead, on the grounds that when you make up an "arbitrary" value it's a bad sign. In fact making this change led me to a deeper understanding of what the algorithm could do and a clarifying shift in its structure. (Amongst other things, the original code actually _relied_ on infinity + finite > infinity, which is not the way infinities are supposed to behave.) Representing Maybe as Either with an arbitrary value made up to be the "missing" value seems to me like just such a bad sign.

Actually, Left absurd is perfect Nothing (mind laziness!). On the other hand, with Either () a you have 2 different Nothings: Left ()and Left _|_. 2014/1/10 Dan Frumin

On 10 Jan 2014, at 04:17, John Lato wrote:

On Thu, Jan 9, 2014 at 8:51 AM, Artyom Kazak wrote:

...

On 01/09/2014 08:36 PM, Vlatko Basic wrote:

...

But instance declarations wouldn't be needed because we already have all the instances for Either. The point would be to have them unified.

Consider a generic Show instance for Either – there’s no way¹ to make it behave differently for Either () (or Maybe if it was a type synonym). I think there are other cases in which we want Maybe to behave differently from Either, but I can’t think of any on the spot.

¹ this point also applies to String, which is a type synonym for [Char] – and it was solved somewhat inelegantly by adding an additional method to Show typeclass *specifically* for showing lists of things.

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).

Also, due to laziness, Either () a is bigger than Maybe a. It should be 'Either Void a'. But Void has only recently been added to the standard-ish library, which means if we'd used Either () from the start now we'd be stuck with the wrong type. I'd rather have a separate Maybe that does exactly what it's meant to.

Why is 'Either Void a' isomorphic to 'Maybe a'. What would 'Nothing' be in this case?

Either () a is the correct version. Roughly speaking 'Maybe a' contains |a|+1 values while Either Void a contains only |a| values, since you can not construct any Left's

John L.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 09/01/14 20:57, Patrick Hurst wrote:

Why have Bool? Just let true = 1, false = 0, (||) = (+), (&&) = (*).

Why have Ordering? Just use Integer and let lt = -1, eq = 0, gt = 1.

Why have three-tuples (a, b, c)? Just use ((a, b), c).

Why have Data.Map a b? Just use a -> Maybe b. You don't even need an Ord constraint any more!

Why have Data.Set a? Just use a -> Bool (or, a -> Integer).

For that matter, why use algebraic data types? data Person = Person String Int is isomorphic to type Person = (String, Int).

Hey, you're right, I should have been using C all along! Thanks for showing me the light. -- Mateusz K.

On Fri, Jan 10, 2014 at 5:12 AM, Vlatko Basic wrote:

However, what I was trying to find out were the reasons for the way it is *implemented*. When I look at the code for Maybe and Either, it seems to me like the violation of the "do not repeat yourself" principle. That principle is taken rather seriously in Haskell. Even HLint has "Reduce duplication" suggestion. *Some* of the code I looked at appears the same.

Less so than you'd think, or there wouldn't be so much resistance to (for example) replacing list-specific stuff in Prelude with the more general Foldable/Traversable ones. The pressure for simple and easy to understand stuff (like Maybe vs. Either () or whatever) turns out to be stronger. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net