csharp-monad

return Option<T>, then you haven't gained anything. I see others on here are taking a similar journey to the one I took over a decade ago. There's an obsession over creating Result types (Either<L, R> and Fin<A> in language-ext, btw) and the other basic monads, but there's no thought as to what comes next. Everyone of them will realise that their result-type is useless if nothing returns it. If you're serious about creating declarative code, then you need an ecosystem that is declarative. And that's why I decided that a project called "csharp-monad" was too limiting, so I started again (language-ext) and I started writing immutable collections, concurrency primitives, parsers, and effect systems (amongst others). Where everything works with everything else. A fully integrated functional ecosytem. The idea is to make something that initially augments the BCL and then replaces/wraps it out of existence. I want to build a complete C# functional framework ecosystem (which admittedly is quite an undertaking for one person). I'm sometimes a little wary about going all in on the evangelism here. C# devs in general tend to 'stick to what they know' and don't always like the new, especially when it's not idiomatic - you can see it in a number of the sub-threads here. But I made a decision early on to fuck the norms and focus on making something good on its own terms. And for those that wonder "Why C#?" or "Why not F#?", well C# has one of the best compilers and tooling ecosystems out there, it's got an amazing set of functional language features, it will have ADTs in the next version, and it has a strong library ecosystem. It also has the same kind of borrow checker low level capability as Rust [3]. So as an all-rounder language it's quite hard to beat: from 'to the metal bit-wrangling', right the way up to monad comprehensions. It should be taken more seriously as a functional language, but just generally as a language that can survive the turmoil of a long-lived project (where mostly you want easy to maintain code for the long-term, but occasionally you might need to go in and optimise the hell out of something). My approach will piss some people off, but my aim is for it to be like the Cats or Scalaz community within the larger Scala community. It's certainly a labour of love right now. But, over a decade later I'm still enjoying it, so it can't be all bad. (PS Mike, I have new highly optimised Foldable functionality coming that is faster than a regular C# for-loop over an array. Watch this space!) [1] https://github.com/louthy/csharp-monad [2] https://github.com/louthy/language-ext [3] https://em-tg.github.io/csborrow/

ople keep using it because they don't want to argue. Clojure really lends it self to that kind of a thing where you do that "smart thing" to solve "that one problem" that ends up being a pointless mess that's hard to maintain and reason about.

I'd already had an interest in functional programming piqued by LINQ and Erik Meijer's talks on Haskell. I spent some time learning Haskell and F#, and came to the understanding that the stability and reliability of a system could be massively improved if null didn't exist, if objects were immutable by default, and if functions were pure/referentially transparent. Expression oriented programming became my order-of-the-day, but C# kept getting in the way. Unfortunately I couldn't just drop it and move to F# because our code-base is huge and written in C#. So that's when I started writing csharp-monad [1], it was my first attempt at bringing functional concepts into C#. It had a couple of problems though, and they were: * The types were classes, and therefore if a function returned Option<T> then it could still be null * It followed the '.NET BCL way' of having functions like GetValueOrDefault() - again breaking the safety net that an Option type (for example) is supposed to give. It had benefits though, primarily that I could make composable computations with the various monads (using LINQ). The problem with that approach was that it quickly bumped up against the rest of the BCL. And, in my case, the rest of our multi-million line C# OO app. So I mothballed that project to an extent. I'd use it now and again where I had control over a process end-to-end. But it got me thinking, that the main issues I had were: 1. Non-expression based C# constructs (if/else, switch, etc.) 2. OO-heavy core types, like List<T>, Dictionary<K,V>, etc. 3. Whenever I brought in 3rd party libraries that 'did functional', they wouldn't work with my Option type in csharp-monad, or any of my functional types - and they never could because there's no baseline for functional (other than LINQ) in C#. 4. The lack of more expressive LINQ grammar makes it less useful and sometimes more cumbersome than Haskell's 'do' notation or F#'s computation expressions. 1-3 cries out for an equivalent of a BCL for functional constructs. I was under no illusion how big a job that would be, but I could see real value in it: a unified set of types for Option, Either, Try as well as collections Lst, Map, etc. "A functional prelude for C#" And once I saw that C# 6 allowed 'using static' I saw that as an opportunity to really create a 'functional BCL' that actually looks like a functional language. A chance to take C# in a more Scala-like direction (which if you think about it, is where it's going, it just doesn't have the libraries to support it). So that's when language-ext [2] was born. Item 4 was more problematic. I couldn't create more LINQ grammar. So I started thinking about it in a different way. Mostly I wanted to create expression oriented code. It was just safer. But with C# OO you always hit that expression boundary. So I thought about how I could control the boundary. Some of that was to build 'matching' constructs into the core types, but that wouldn't deal with all boundary issues. That's where the actor system comes in (LanguageExt.Process [3] ). I'd looked at Akka.net and its very Java-like API horrified me - it looked like C# 1.0. So I took the idea that a LanguageExt Process (an actor) is a fold over a stream. That suddenly created a very powerful idea that I could create packets of pure computation and wrap them with their state, and each message would evolve that state. In one fell swoop it created a better and more controlled OO that can interact with pure functions - and all fully integrated with the functional BCL I'd developed. It also allowed us to start breaking up our monolithic app in a much more controlled way. So yeah, that's the back story! Sorry if it turned into War & Peace. Btw, I am in the market for two developers at the moment. So if none of what you just read horrified you, please drop me an email with your CV to plouth AT gmail :) [1] https://github.com/louthy/csharp-monad [2] https://github.com/louthy/language-ext [3] https://github.com/louthy/language-ext/blob/master/LanguageE...

} class Thing T : BaseThing T { } It's moot anyway really, it is what it is. I've just found it cognitively challenging over the years. [1] https://github.com/louthy/csharp-monad

var result = (from lhs in Two() from rhs in Two() select lhs + rhs) .Match( Right: r => r * 2, Left: l => 0 ); [1] https://github.com/louthy/csharp-monad