C# has native support for monads (LINQ), so it's trivial to implement an Option monad.
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();
Which is arguably even more elegant than the Scala 'for' notation.
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.
It doesn't do higher-kinded polymorphism, no. If you're referring to something else, please elaborate on what it can't express. But for the example given in the blog piece it's exactly as expressive and concise - so it's not giving C# a fair hearing.
It is actually possible to get most of the way to HKT using extension methods. But it involves a hell of a lot of typing. In my project I used a template generator to do it. It's still pretty limited though, and there isn't a single type-class called Monad.
The point is that you can't leverage all the existing monad/functor/applicative/free/yoneda... libraries out there–they don't exist, because they can't be written in a way that would allow re-use.
> all the existing monad/functor/applicative/free/yoneda... libraries out there–they don't exist
Agreed. I can only hope one day that the CLR team decide it's a reasonable thing to support so that C# (and F#) can both support it. It seems to be the blockage to the language teams (they won't move without it, even if they could implement it in a weaker/slower way on top of the existing type system). I've jumped through many hoops to get as much of a functional 'base class library' as possible in C# (I needed it for a very large C# project I maintain and want to bring more stability to), but language support would be preferred.
Just out of curiosity what kind of reusable monad libraries are out there for Scala/Haskell? Given the scope of everything between Maybe and IO, I've never understood what one could make that would be useful to "monads" in general (beyond the sugar for do-notation).
So in F# I've been using specialized asyncSeq and asyncMaybe libraries. With monad transformers (and thus HKT's), would those come largely for free?
And you could traverse a list<maybe<list<_>> combo like
[Some [Some [1; 2]; None; Some [3]]; None; Some [None; Some [4]]] with no more difficulty than a regular list-of-lists?
You can also write a generic "sequence" over a list, for instance, so that any 'monad' (task/future, maybe/option, state, either/disjunction etc.) can 'swap places'.
So your List<Future<A>> can become Future<List<A>>. But you only need to write it once. Then it doesn't matter what the inner type of the List is, as long as it's a monad (applicative, really, but all monads are applicatives).
Crazy, I'd always considered monad transformers a sore thumb on, well, all that stuff. The fact that monads weren't enough but then you had to go reproduce all that stuff in monad transformers as well. The whole thing just reeked of code duplication and bad smells so I didn't really look into it further.
Now looking at the Scalaz impl, the transformers are actually the core thing, and monads themselves are just transformers over Identity. So it all fits and isn't redundant. Certainly changes a lot of perspective.
That said, I'd still put LINQ as 99% of "the deal" per the original comment. The extra abstractions allowed by HKT's, while "necessary" mathematically, still only save me about 1% of the work required to implement asyncSeq and asyncMaybe, and in 15 years of pro experience those are the only real uses of HKT's I've ever had the need for.
For one example, in Haskell, all Monads are also Functors. This means you can `fmap` a function over a Maybe Foo just as you would over a [Foo] (read list of Foo) or Vector Foo or indeed an IO Foo.
Trivial to implement but not compatible if we both implemented. That's the main benefit of Scala Optional, its baked-in -- I don't have to worry about writing adapter to use your library.
Agreed, there is no functional base with C# aside from LINQ. So if you want to do functional in C# you would have to chose a library, and that's why I went so far building the rest of the functional infrastructure around it. It'd be insane to use multiple Option implementations. My first attempt at bringing common monad support in C# [1] suffered from the problems you state.
But that still doesn't change the crux of the blog post, it's disingenuous comparing the Option monad to a null coalescing operator.
[Author] I wasn't trying to say that Option monad is better/worse than null conditional. My point was to compare two different approaches to the same problem.
As usual when someone tries to get into explaining monads, mistakes happen.
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.
I agree on the first point. As to the second, I didn't mean that having flatmap is the reason why we can combine Options and Lists. I meant that Options are composable with other Options and Lists are composable with other Lists.
I understand the problem of working with different monads. I looked into monad transformers at some point and found them difficult to work with so my approach now is to avoid mixing monad types (for example instead of having Future[Option[T]], just use a failed Future instead of None).
Why not just use less dots to begin with? Or, in other words, apply the Law of Demeter[0]. To me, diving so many levels deep into dependencies is a code smell because it tightly couples code to sub-dependencies and makes refactoring more difficult.
But for just structured data it's not constructive to write accessor wrappers at each level. And for things like recursive data structures, it's not even possible.
Monads are very useful for what OO people sometimes call "cross-cutting concerns" - something that's relevant at many levels but not the primary purpose of any one function. E.g. error handling, async, audit logs, database transaction boundaries.
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.
The null-conditional operator is a language feature. The Option monad is a class in the standard library.
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.
It's really not. I worked for a .NET shop that migrated some new projects to Scala. We evaluated F#, but decided the power of Scala was worth the platform switch. F# lacks higher kinds and implicit parameters, meaning you can't really use the type class pattern. This hurt our productivity.
It can be done in F# [1], but it's not pretty, and absolutely nails the compiler. The fact that the compiler can be cheated into doing it makes it even more frustrating that there isn't some official support.
It's just annoying to have to re-implement sequence/traverse and every combination of monad stacks you want to for each type. It's doable, but bug prone and frustrating.
I now work for one of the largest scala teams in the US. We make heavy use of the Scalaz project and regularly use monad transormers or free monads and both require higher kinded types.
Or you can go the whole hog like I have my language-ext project [1][2].
In C# it would look like this:
Which is arguably even more elegant than the Scala 'for' notation.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...