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

Re:Scala's Option monad versus null-conditional operator in C# by louthy on Saturday February 20, 2016 @05:11PM (#11142201)

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.

[ Parent | on HN ]

Re:Scala's Option monad versus null-conditional operator in C# by airless_bar on Saturday February 20, 2016 @05:29PM (#11142275)

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

[ Parent | on HN ]

Re:Scala's Option monad versus null-conditional operator in C# by louthy on Saturday February 20, 2016 @05:40PM (#11142314)

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

[ Parent | on HN ]

Re:Scala's Option monad versus null-conditional operator in C# by daxfohl on Saturday February 20, 2016 @06:40PM (#11142519)

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

[ Parent | on HN ]

Re:Scala's Option monad versus null-conditional operator in C# by runT1ME on Saturday February 20, 2016 @06:46PM (#11142536)

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

is a nice tutorial series on it.

[ Parent | on HN ]

Re:Scala's Option monad versus null-conditional operator in C# by daxfohl on Saturday February 20, 2016 @08:34PM (#11142870)

Ah, light bulb moment (perhaps).

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?

[ Parent | on HN ]

Re:Scala's Option monad versus null-conditional operator in C# by runT1ME on Saturday February 20, 2016 @08:46PM (#11142902)

Exactly!

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

[ Parent | on HN ]

Re:Scala's Option monad versus null-conditional operator in C# by daxfohl on Sunday February 21, 2016 @09:20AM (#11144561)

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.

[ Parent | on HN ]

Re:Scala's Option monad versus null-conditional operator in C# by daxfohl on Thursday March 03, 2016 @01:41PM (#11218889)

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.

[ Parent | on HN ]

Re:Scala's Option monad versus null-conditional operator in C# by louthy on Saturday February 20, 2016 @07:09PM (#11142616)

Monad transformers in C# [1] (but yes, only works with the monads in the library)

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

[ Parent | on HN ]

Re:Scala's Option monad versus null-conditional operator in C# by chongli on Saturday February 20, 2016 @11:44PM (#11143340)

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.

[ Parent | on HN ]

Re:Scala's Option monad versus null-conditional operator in C# by tome on Sunday February 21, 2016 @06:59AM (#11144173)

lens, for example (which is not really a "reusable monad library" but very much of that flavour).

[ Parent | on HN ]