Scala's Option monad versus null-conditional operator in C#

Or you can go the whole hog like I have my language-ext project [1][2].

In C# it would look like this:

    var city = from author  in article.author
               from address in author.address
               from city    in address.city
               select city.ToLower();

As an aside, there was a discussion [3] on one of the language-ext issues about my Try<T> implementation, and I was asked to compare it to Scala's Try monad. The crux of it was that it's perfectly possible to capture the majority of the use-cases, but may be of interest in the context of this discussion.

[1] https://github.com/louthy/language-ext

[2] https://github.com/louthy/language-ext/blob/master/LanguageE...

[3] https://github.com/louthy/language-ext/issues/33#issuecommen...

First, on the scala standard library and monads: Scala very carefully avoided creating a Monad trait, on purpose. So while List and Options are monads, we can't just go and say that everything that has a flatmap is a monad.

Also, the reason we can combine options and lists in a for comprehension is not really that they both have a flatmap: Try doing that with Future instead, and it will not work quite so easily! The reason those two have such easy interoperability is that in Scala's Predef there is a conversion that turns an Option into a Traversable, which is being called under the covers. For comprehensions are very powerful, but switching from one monadic context to another without help isn't one of them. In the case of Future and List, for instance, we'd have to use some of the utility methods in the Future object that can help transform a future into a List[Future], and a List[Future] into Future[List]

Don't get me wrong, it's great to see people trying to explain this kind of stuff, but it is so very hard to cover the topic in a way that is both approachable and that doesn't leave people with intuitions that will fail them outside of the given example.

    type Address = { street : string; city : string option }
    type Author = { name : string; email : string; address : Address option }
    type Article = { title : string; content : string; author : Author option }

    let printCity (article : Article) =
        article.author
        |> Option.bind(fun author -> author.address)
        |> Option.bind(fun address -> address.city)
        |> Option.iter(fun city -> printfn "%s" city)

article.author.flatMap(_.address).flatMap(_.city).map(_.toLowerCase).foreach(println)

And in for-comprehension version there is no need to use yield, as we don't need result of println.

0. https://en.wikipedia.org/wiki/Law_of_Demeter

Option/Maybe can represent arbitrary optionality, while null is limited to a sentinel value.

I wrote a blog post about null (https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...) and this one of the examples:

Suppose you have a generic key-value store. If a value is not present, the lookup returns null. You use it for a cache that maps user IDs to phone numbers. Some people don't have phone numbers, i.e. their phone number is null. But now you can't represent that in your cache. (JS "fixes" this -- if you want to call it that -- by using a second type of null: undefined.)

Option is generic and can applied arbitrarily deep; null/Nullable is a sentinel that can be used once.

Option is arbitrarily composable, and the superior choice.

You can have Option in C# and use it with linq to get more or less the same feature and syntax. There are a few implementations on nuget if you don't want to write your own.

    (println (some-> article :author :address :city upper-case))

I know that's by far not as good looking as the c# version, however at the end all comes down to syntactic sugar.

  Console.WriteLine(article?.Author?.Address?.City?.ToUpper());

Another reason to set tab stops to 4+ characters: make PoDs impractical and better code legible.