Monads in Modern C++ - Georgi Koyrushki and Alistair Fisher

Monads in Modern C++ - Georgi Koyrushki and Alistair Fisher - ACCU 2023

Рет қаралды 6,171

Күн бұрын

ACCU Membership: tinyurl.com/ydnfkcyn
Sponsored By think-cell: www.think-cell.com/accu
accu.org
Monads in Modern C++ - Georgi Koyrushki and Alistair Fisher - ACCU 2023
Slides: accu.org/conf-previous/accu2023/
Monads are a common technique in functional programming languages to reduce boilerplate, abstract detail in order to produce simple, pure pipelines. While traditionally associated with languages like Haskell, monads are making their way into more mainstream languages, including C++ -- with monadic operations being added in C++23. In time, these functional techniques may become core pillars of C++ development.
To many developers, monads are either unknown or confusing -- they have a reputation as being notoriously difficult to understand. This talk, which will combine both theory and coding examples, aims to demystify the monad and enable attendees to gain insight into its internal workings.
While the focus of our talk will be on C++, the ideas are relevant to any other programming language -- the shift towards these functional features is not unique to C++.
No functional programming knowledge required.
This talk will serve as an introduction to the monad design pattern. We will start by introducing functors (a related pattern) and use it as a building block to introduce monads. Throughout the presentation, we will show examples of how monadic operations can help turn our imperative-style code into succinct functional pipelines, while removing boilerplate, error-prone control flow, and side effects. The examples will relate to recent and upcoming developments for std::vector and std::optional in the C++ standard. Finally, the talk will incorporate a walk-through of the available monadic support in C++, and we will discuss where C++ stands in comparison to other languages.
---
Georgi Koyrushki
---
Alistair Fisher
---
www.accuconference.org/
KZbin Videos Filmed, Edited & Optimised by Digital Medium: events.digital-medium.co.uk
#accuconf #programming #monad

Пікірлер: 9

@GxdKxller 11 ай бұрын

Would have loved to see a performance overhead graph for this

@bernhardmanfredgruber7156 8 ай бұрын

yeah, I immediately wondered about that with the std::vector monad, turning a single loop with three elemental functions into three. I wondered if the compiler can fuse the loops back again, otherwise there would be three passes over memory instead of one.

@georgikoyrushki7825 8 ай бұрын

Things like std::ranges would do a single iteration with the functions applied all together on each element. Would translate more or less to the imperative way of doing it. I have attended a few talks recently mentioning that higher level, more expressive abstractions, actually end up allowing the compiler to carry out better optimizations. Ending up being faster in the end, contrary to what you would think. Either way, the talk was more going over the concepts, rather than worrying over performance. It should have been mentioned that if you're on a hot path within a low latency environment: always carry benchmarks when choosing ur poison. For a general purpose use case, however, you would win on average, if you go for the simpler, more expressive and understandable way of doing things.

@ErikBongers 3 ай бұрын

The main reason to write an algorithm in a functional way: "So, here I wrote an imperative version of this [...] there's nothing particularly wrong with this code [...] but I didn't really feel very fulfilled writing this code..." ok...

@aniketbisht2823 11 ай бұрын

awesome!

@ACCUConf 11 ай бұрын

Thanks!

@gonzajuarez4918 11 ай бұрын

I've recently started paying attention to the sender/receiver proposal. Receivers, representing some sort of callback, remind me a lot of continuation passing style. There is one of eric niebler's talk from cppcon 21 where he explains the nesting of operation_state, senders, and receivers, and it looks a lot like an explanation on CPS. Squinting your eyes hard enough, it is possible to see a bit of the Cont monad spill from senders/receivres. Haskell with Cont monad: factorialS :: Int -> Cont r Int factorialS x = reduceS (*) 1 (rangeS x) where rangeS x = return [1..x] reduceS op init xs = fmap (foldl op init) xs C++'s libunifex library: auto factorialS (int x) { return range_stream{1, x + 1} | reduce_stream(1, [](int acc, int x){ return acc * x; }); } One difference I've found so far is that recursive definitions of functions are not possible - skill issue? - due to senders being template expressions (the whole expression must be in the code at compile time). But recursive schemes can be achieved through sender algorithms anyways ;)