[kelnos]

So maybe this is just a terminology thing, but, isn't Maybe the same thing as:

1. By default all types are non-nullable. 2. You explicitly mark if you expect that a value could be null. 3. The compiler helps you by either making sure you check for null on those values you mark, or by doing some magic (like Scala does) that will always return null for expressions where one of the values is actually null.

Is the reason we call it Maybe/Option/whatever just to disambiguate with the traditional use and lack of safety in what pretty much all languages use "null" for? Or is there a distinction I'm missing?

[tikhonj]

Yes, it's the same idea. The main difference is that Maybe is just a normal type in languages like Haskell and OCaml--you do not need any especial compiler support for it.

So to use Maybe, all you need from the compiler is to not have nulls everywhere. Since you don't need language support for it, your language is simpler and the Maybe behavior is part of a library.

This also ensures that you Maybe values behave as first-class citizens. You can do anything with the Maybe type that you could with any other type, because that's all it is. For example, this means that you can nest them: have a Maybe<Maybe<A>> value, for example. It also means Maybe can play well with other libraries; for example, inn Haskell, it works immediately with the alternation operator:

    result = tryA "foo" <|> tryA "bar" <|> tryB

Part of the beauty is that <|> is an operator that represents alternation for a whole bunch of other types as well. There are a whole bunch of other functions like this.

So: yes, you can have language support for it. But just having it as a normal type makes the language simpler and ensures you have full generality. The only thing that you need from your language is to get rid of null.

[salmonellaeater]

You DO need special compiler support for Maybe! Specifically, you need algebraic types. Consider Java. There is no pattern matching and no syntactic construct to decompose algebraic types. So an Option has to be cast to Some before extracting its value, risking a ClassCastException if the Option was actually a None. This is just as bad as having nulls, since programmers will just cast without looking.

[tikhonj]

My point was that you do not need to support Maybe explicitly. Instead, it naturally flows from significantly more general language features; Maybe itself is just a normal type built with these features.

Following your argument, we need special language support for any sort of abstraction, because everything has to be built in terms of some built-in language features at some point.

Also, on a largely unrelated note, I think that there is no reason for modern languages not to have sum types in this day and age. (cough Golang cough)

[Peaker]

Alternatively, you could implement Maybe in Java safely using the visitor pattern. Cumbersome, but it can work.

[MichaelGG]

The difference is that Maybe or Option is something you can implement in library code, it does not require any special compiler implementation.

Also, most languages require something to be a reference or pointer to be null. You can't have a plain int or structure be null.