The aim of this series of articles is to present computation expressions in detail, with their underlying functional patterns–monoid, monad and applicative–since these patterns enable computation expressions classification.
This offers an alternative approach to–to name but a few–the concise Microsoft documentation, which refers to these patterns without going into further detail, and Scott Wlaschin’s brilliant series, which preferred not to mention these functional patterns for understandable pedagogical reasons.
These articles also provide a means of introducing these functional patterns to F# developers, with direct application to understanding and realizing computation expressions.
I hope these articles will help F# beginners to get started writing your own computation expressions. Note to the experts: if you see any errors, please let me know.
You did a lot of work on trying to explain these concepts. Nice, however I think it is unfortunate with all the category theory jargon. Microsoft official docs deliberately steer away from that. When I was learning F# as a C# dev, all of that terminology present in lots of blogs really side tracked for a long time. It was only after dabbling with F# for years that I could start to use it simply, without trying to design one monoid after the other. Even D Syme talks about this in his talks on YouTube (F# code I love).
I will clarify my point of view on this subject, expanding on what I mentioned in the introduction to the series, in order to better explain the value of this series for a fraction of F# developers who have not found what they were looking for in the documentation on F# so far.
As F# developers, generally coming from C# like you and me, we are in a delicate position: we don’t know where we stand regarding functional patterns derived from category theory such as monoid, monad, and applicative. On the one hand, Don Syme’s choice not to model them in the language is a wise one for many reasons. So, in principle, it is not necessary to know them in order to program in F#. On the other hand, when it comes to understanding how computation expressions work, these patterns provide a precise and standard description of their behavior: monoidal, monadic, and/or applicative. This is why Microsoft mentions them in the documentation—contrary to what you said, sorry—but without ever explaining them either in general terms or in relation to computation expressions.
It is therefore unfortunate that there is no documentation on them aimed at F# developers. Scott Wlaschin had already done a tremendous job of describing computational expressions on the one hand and these patterns on the other, without even naming them, but without crossing these two subjects! This series of articles complements that work by addressing those who want to call a spade a spade. In addition, it facilitates bridges with other functional languages such as Haskell and OCaml, for which there is more extensive documentation related to category theory.
Before completing this documentation work, I felt like I was just winging it. Sure, I could have ended up getting it right through trial and error, but having a solid grasp of the subject matter gives me a welcome sense of comfort. That’s why I recommend that F# developers—who have sufficient experience and are committed to continuous learning—invest in learning its functional patterns.
I hope this series of articles will be beneficial to them, and perhaps to you in the end? I also understand that it may be different, no problem.
Thank you for your thoughtful response. I have done a few computation expression implementations myself and found the documentation completely lacking. Somewhere there was a reference to test code by Mr Syme, to use as the CE reference itself. When I implemented CEs I thank ChatGPT. Without it I simply wouldn’t have finished. That’s very unfortunate as these concepts are so powerful and useful.
