4 ms·

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

by louthy 11y ago

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. [1] https://github.com/louthy/language-ext https://github.com/louthy/language-ext [2] https://github.com/louthy/language-ext/blob/master/LanguageExt.Core/Option.cs https://github.com/louthy/language-ext/blob/master/LanguageE... [3] https://github.com/louthy/language-ext/issues/33#issuecomment-146557934 https://github.com/louthy/language-ext/issues/33#issuecommen...

airless_bar 11y ago
Implementing a monad is only 30% of the deal. Being able to abstract over monads (and other type constructors) ... that's the part that really matters. C# is not expressive enough for that.
- louthy 11y ago
  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.
  - airless_bar 11y ago
    > It doesn't do higher-kinded polymorphism, no. That's what I referred to. > ... 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.
    - louthy 11y ago
      > 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.
    - daxfohl 11y ago
      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).
      - runT1ME 11y ago
        https://github.com/scalaz/scalaz https://github.com/scalaz/scalaz Monad Transformers for one. Traverse/Sequence are another super common (amazing) pattern that requires abstracting over types. http://eed3si9n.com/learning-scalaz-day12 http://eed3si9n.com/learning-scalaz-day12 is a nice tutorial series on it.
        louthy 11y ago
        Monad transformers in C# [1] (but yes, only works with the monads in the library) [1] https://github.com/louthy/language-ext/blob/master/LanguageExt.Tests/OptionTTests.cs https://github.com/louthy/language-ext/blob/master/LanguageE...
dk8996 11y ago
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.
- louthy 11y ago
  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. [1] https://github.com/louthy/csharp-monad https://github.com/louthy/csharp-monad
  - miloszpp 11y ago
    [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.
jb55 11y ago
I have a standalone implementation here as well: https://github.com/jb55/Data.Maybe.cs https://github.com/jb55/Data.Maybe.cs
wantreprenr007 11y ago
This article is timely for us as we're using Scala for backend work. Ruby 2.3 &. operator and Swift can do something like this pseudocode: if let city = article?.author?.address?.city?.ToLower() { // city present } Too long?: if let city = article? .author? .address? .city? .ToLower() { // city present } All are improvements over pyramids of doom. (Be aware of subtle gotcha in Scala of var and val, really prefer Rust/Go/Swift keywords.)

by louthy 11y ago

airless_bar 11y ago

Implementing a monad is only 30% of the deal. Being able to abstract over monads (and other type constructors) ... that's the part that really matters. C# is not expressive enough for that.

louthy 11y ago
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.
- airless_bar 11y ago
  > It doesn't do higher-kinded polymorphism, no. That's what I referred to. > ... 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.
  - louthy 11y ago
    > 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.
  - daxfohl 11y ago
    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).
    - runT1ME 11y ago
      https://github.com/scalaz/scalaz https://github.com/scalaz/scalaz Monad Transformers for one. Traverse/Sequence are another super common (amazing) pattern that requires abstracting over types. http://eed3si9n.com/learning-scalaz-day12 http://eed3si9n.com/learning-scalaz-day12 is a nice tutorial series on it.
      - louthy 11y ago
        Monad transformers in C# [1] (but yes, only works with the monads in the library) [1] https://github.com/louthy/language-ext/blob/master/LanguageExt.Tests/OptionTTests.cs https://github.com/louthy/language-ext/blob/master/LanguageE...

dk8996 11y ago

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.

louthy 11y ago
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. [1] https://github.com/louthy/csharp-monad https://github.com/louthy/csharp-monad
- miloszpp 11y ago
  [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.

jb55 11y ago

I have a standalone implementation here as well: https://github.com/jb55/Data.Maybe.cs https://github.com/jb55/Data.Maybe.cs

wantreprenr007 11y ago

This article is timely for us as we're using Scala for backend work. Ruby 2.3 &. operator and Swift can do something like this pseudocode: if let city = article?.author?.address?.city?.ToLower() { // city present } Too long?: if let city = article? .author? .address? .city? .ToLower() { // city present } All are improvements over pyramids of doom. (Be aware of subtle gotcha in Scala of var and val, really prefer Rust/Go/Swift keywords.)