language-ext

comprehensions and allows for the building of truly generic trait-based behaviours. Something that just doesn't really exist in C#. In language-ext today I have `Foldable<F>`, which is a little bit like `IEnumerable`, but pure. I want to be able to provide a super efficient set of default implementations for any `Foldable` (or enumerable/iterable). For this I need an efficient lazy-stream or co-routine system. The one built-in to C# (`IEnumerable` and `IEnumerator`) is impure (it mutates as it enumerates), so I am trying to build an efficient iterator/enumerator that: * Takes around 0.25 nanoseconds per-iteration-step for its housekeeping (this speed is then on a par with the mutable IEnumerators that are a core part of C#). * Doesn't allocate any memory * Is immutable * Is lazy * Can be stopped at any point and the iterator reference be passed around (because it's immutable) * Can be composed with standard functional operators (functor map, applicative apply, monad bind, etc.) without performance degradation and without a large memory-allocation cost. I've been building several prototypes to try different ways of bending C# to my whims. I've managed all but the last item on that list. Not allocating memory means using value-types (stack allocated types), but that also means the entire state of the co-routine needs to be stored in the value-type as each value is yielded (because control needs to be given back to whatever code is processing the values). To solve it, I'm pretty much building my own runtime, stack-machine, and memory manager on top of the .NET CLR so that I don't have to submit to its rules. I'm trying to apply as many of my old-skool low-level engineering chops as I can (without making it brittle); but to do the last item on that list needs more space in a value-type than would be reasonable (to avoid copying costs), so I'm looking at other pooling strategies and into building lots of bespoke to-the-metal memory managers. After all of that, it may be a fools errand, and not doable. The LLM wouldn't understand, and that's for just one feature! Also, it must be stated, I just love doing this shit, it's brain fuel. The idea of having this conversation endlessly with an LLM as it continuously gets it wrong is nightmare fuel. I'm not anti-AI, I love the fact that people who can't, now can. But, at this point in my journey with code, I think quicker and can produce quicker than an LLM. I think it's akin to a virtuoso piano player. If the piano player had to describe what they wanted to an LLM, the magic would go, the enjoyment would go, and potentially the quality would go. It would it also take much longer than if they had just played. That's how I feel with code. An LLM can maybe churn out more code than me, but I can build more value and I can invent. And when in my flow state, nothing can stop me. I will certainly keep checking in though, I'm sure there'll be a point where I feel like it augments me rather than hinders. It's just not there for me yet. Too much information? :D [1] https://github.com/louthy/language-ext [2] https://github.com/louthy/iterator-prototype (this is messy prototype code, don't hate me).

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/

ing)> minimal(bool b) => from x in b ? Seq(1, 2) : Seq(3, 4) from r in x % 2 == 0 ? from y in Seq("a", "b") select (x, y) : from y in Seq("y", "z") select (x, y) select r; It yields: [(1, y), (1, z), (2, a), (2, b)] [(3, y), (3, z), (4, a), (4, b)] Which I think passes your test. [1] https://github.com/louthy/language-ext/blob/main/Samples/Car...

riting of any function constrained to said trait. For example, a `When` function that runs the `then` monad when the `predicate` monad returns `true` for its bound value: public static K<M, Unit> When<M>(K<M, bool> predicate, K<M, Unit> then) where M : Monad<M> => predicate.Bind(flag => flag ? then : M.Pure(unit)); This will work for any monad, `Option`, `List`, `Reader`, ... or anything that defines the trait. So types like `Option` are just pure data-types. They become monads when the Monad trait is implemented for them. The monad trait can be implemented for data-types and function-types. Reader, for example, has the Monad trait implemented for the function: Func<E, A> btw, monads also inherit behaviour from applicative and functor. The ability to lift pure values into the monad (a -> m a) is vital to making monads useful. This is `select` in LINQ, `pure` in Haskell's Applicative, and `Pure` in language-ext's Applicative [2]. [1] https://github.com/louthy/language-ext/blob/main/LanguageExt... [2] https://github.com/louthy/language-ext/blob/main/LanguageExt...

ut the newsletters from my blog. Happy to answer any questions on it. [0] https://github.com/louthy/language-ext/ [1] https://paullouth.com/higher-kinds-in-c-with-language-ext/ [2] https://paullouth.com/higher-kinds-in-csharp-with-language-e... [3] https://github.com/louthy/language-ext/tree/main/Samples/New...

an get in C#. It's certainly pushing the language, but is still elegant (in my eyes anyway). [1] https://github.com/louthy/language-ext [2] https://github.com/louthy/language-ext/blob/main/Samples/Car... [3] https://github.com/louthy/language-ext/blob/main/Samples/New... [4] https://paullouth.com

on and into its runtime — making the language itself pure, even if the runtime isn’t. This isn't just a Haskell thing though. I'll write code this way in C# (and have built a large pure-FP framework for C# to facilitate this approach [1]). Here's an example of the more 'narrative style' [2] of C# using pure-FP. It reads from top-to-bottom, keeping the related functions near each other and walking the reader through the functionality. There's also a massive removal of the usual clutter you see in C#/Java programs, getting down to the essence of the logic. It won't be to everybody's taste (as it's not idiomatic at all), but it demonstrates the idea. This style works well for regular program logic and less well for things like APIs where there's not always a narrative you can tell. [1] https://github.com/louthy/language-ext [2] https://github.com/louthy/language-ext/blob/main/Samples/Car...