Hi Shishir, Indeed, Maybe doesn't grant you additional operational functionality that other languages lack. Most use-cases of Maybe can be matched in nearly all mainstream languages through the use of NULL. Maybe illustrates a desired lack of functionality in cases where it is absent. For example, in Java: public static Integer myMethod(Integer a, Integer b) { // body} What do we know about this method from the signature? You would think it is a method that takes two integers and returns an integer, but really it could take NULLs too, and could possibly return a NULL. Here is the equivalent Haskell signature: myMethod :: Maybe Integer -> Maybe Integer -> IO (Maybe Integer) We can see that Maybe allows us to replicate the possibility of NULL values from other languages... But how is that special since other languages already have this built-in. Now look at the following Haskell signature: myMethod :: Integer -> Integer -> Integer Now what do we know about this? We know that it takes two Integers and returns an Integer. This is the power that comes from having Maybe as the canonical way to represent the possibility of missing values. On Thu, Mar 26, 2015 at 9:06 PM, Shishir Srivastava < shishir.srivastava@gmail.com> wrote:

Hi,

After reading and re-reading the haskell tutorials I don't happen to see a very convincing or appealing reason for having these data types.

Can anyone please explain where Maybe and Just provide the sort of functionality that cannot be achieved in other languages which don't have these kind.

Thanks, Shishir Srivastava

_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

Hi, On 2015-03-26 11:06, Shishir Srivastava wrote:

After reading and re-reading the haskell tutorials I don't happen to see a very convincing or appealing reason for having these data types.

First of all, only one of them is a type (or a 'type constructor'): "Maybe". "Just" on the other hand is a "data constructor", i.e. "Just 'x'" will yield a value of type "Maybe Char".

Can anyone please explain where Maybe and Just provide the sort of functionality that cannot be achieved in other languages which don't have these kind.

They don't provide anything which other languages cannot achieve. 'Maybe' values merely indicate that you *maybe* get a value. This is useful for functions which might not be able to yield a meaningful result. Consider a 'safeHead' function which works like 'head', returning the first element of a given list. What should it do for empty lists? Something like 'Maybe' is useful because it 1. Makes potential errors clearly visible in the type system: If a function returns a 'Maybe Char', you know that it possible won't yield a Char (but rather 'Nothing'). Raising an exception is totally opaque to the caller. 2. Clearly separates the values which might represent failures from those which don't. Contrast this with e.g. Java, where every object of every type can be null. If every value is potentially 'null', you either have to check using if() everywhere or use assertions. With 'Maybe', the null'ness can be asserted by the compiler. 3. Relieves other types from having an explicit 'Invalid' value. Consider: data Color = Red | Green | Blue | Invalid -- Parses a color string; yields 'Invalid' if the string is malformed parseColor :: String -> Color parseColor = undefind With a setup like this, *every* code dealing with 'Color' values will have to be able to handle 'Invalid' colors. It ripples through the system. OTOH, something like data Color = Red | Green | Blue -- Parses a color string; yields 'Nothing' if the string is malformed parseColor :: String -> Maybe Color parseColor = undefined Clearly separates the valid colors, such that only the caller of 'parseColor' only has to check for 'Just x' values - and if it got one, it can pass the 'x' value to other code. For what it's worth, other languages have similiar concepts. For instance, C++ programmers can use 'boost::optional' (which, alas, didn't make it into C++14). -- Frerich Raabe - raabe@froglogic.com www.froglogic.com - Multi-Platform GUI Testing

Am 03/26/2015 um 11:06 AM schrieb Shishir Srivastava:

Hi,

After reading and re-reading the haskell tutorials I don't happen to see a very convincing or appealing reason for having these data types.

Can anyone please explain where Maybe and Just provide the sort of functionality that cannot be achieved in other languages which don't have these kind.

My intuition goes like that: "Maybe" is like "nullable" (which doesn't really exist, but you sure can imagine what it means). In many programming languages a variable of any type can contain "null", i.e. every type is nullable. This means that any function accepting one of these types as a parameter must be prepared to see a null. You end up with many checks like if (x==null) {return null;} Not so in haskell. An Int is really an Int and Ints cannot be null. Functions accepting Ints don't have to check for null. But you can beef up any datatype to be nullable. You can create a TYPE "nullable Int" which would be called "Maybe Int" in Haskell. Just like "nullable" alone, Maybe itself is not a type, but an up-beefer of another type. There are no values of type Maybe, but only of Maybe Int, Maybe String etc. In that respect maybe is like "List". There are no values of type "List", but only of List of Int, List of String. List is an up-beefer too (written as [] in Haskell) Obviously there needs to be a distinct VALUE for "null". In Haskell this value is called "Nothing". For the non-null VALUES you could think about writing them verbatim, like "42". But from just looking at 42, you couldn't tell what type it is. It could be an Int or a Maybe Int. This problem is somewhat akin to writing 42.0 when you want to make sure it is a float (in imperative languages), or 42L to indicate it is a long. So in the same vein, you distinguish an Int (42) from a Maybe Int (Just 42). Just 42 is a value of type Maybe Int, which just (sic!) happens not to be null, but it is still not a plain Int, but a Maybe Int. Like 42.0 is a float which happens not to have any digits after the decimal point but also is not a plain Int but a float.