{"id":5174,"date":"2017-02-10T16:15:36","date_gmt":"2017-02-10T16:15:36","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/monads-in-c\/"},"modified":"2023-06-26T12:23:48","modified_gmt":"2023-06-26T12:23:48","slug":"monads-in-c","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/monads-in-c\/","title":{"rendered":"Monads in C++"},"content":{"rendered":"

Monads in C++? What a strange name for a post. But it’s not so strange. With std::optional<\/span>, C++17 gets a monad. The ranges library from Eric Niebler and the extended futures are also monads. For both, we can hope for in C++20.<\/p>\n

<\/p>\n

Bjarne Stroustrup presented in his Secret Lightning Talk at the Meeting C++ 2016<\/a> a few concepts of Concepts Lite <\/a>that we will get with high probability in C++20. There were also mathematical concepts such as ring and monad. My assumption becomes more and more reality. Modern C++ will be hardened for the future.
<\/strong><\/p>\n

std::optional<\/h2>\n

Haskell’s Maybe Monad inspires std::optional<\/span>. std::optional <\/span>was initially intended to be part of C++14 stands for a calculation that maybe has a value. Therefore, a find algorithm or a hash table query has to deal with the fact that the question can not be answered. Often, you use particular values that stand for the presence of no value, the so-called no result. Often we use a null pointer, empty strings of particular integer values for no results. This technique is expensive and error-prone because you have to deal with the no-results especially. No results are of the same type as regular results. std::optional<\/span> has in case of a no-result no value.<\/p>\n

Here is a short example.<\/p>\n

 <\/p>\n

\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33<\/pre>\n<\/td>\n
\n
\/\/ optional.cpp<\/span>\r\n\r\n#include <experimental\/optional><\/span>\r\n#include <iostream><\/span>\r\n#include <vector><\/span>\r\n\r\nstd::experimental::optional<int<\/span>> getFirst(const<\/span> std::vector<int<\/span>>& vec){\r\n  if<\/span> (!vec.empty()) return<\/span> std::experimental::optional<int<\/span>>(vec[0]);\r\n  else<\/span> return<\/span> std::experimental::optional<int<\/span>>();\r\n}\r\n\r\nint<\/span> main(){\r\n    \r\n    std::vector<int<\/span>> myVec{1, 2, 3};\r\n    std::vector<int<\/span>> myEmptyVec;\r\n    \r\n    auto<\/span> myInt= getFirst(myVec);\r\n    \r\n    if<\/span> (myInt){\r\n        std::cout << \"*myInt: \"<\/span>  << *myInt << std::endl;\r\n        std::cout << \"myInt.value(): \"<\/span> << myInt.value() << std::endl;\r\n        std::cout << \"myInt.value_or(2017):\"<\/span> << myInt.value_or(2017) << std::endl;\r\n    }\r\n    \r\n    std::cout << std::endl;\r\n    \r\n    auto<\/span> myEmptyInt= getFirst(myEmptyVec);\r\n    \r\n    if<\/span> (!myEmptyInt){\r\n        std::cout << \"myEmptyInt.value_or(2017):\"<\/span> << myEmptyInt.value_or(2017) << std::endl;\r\n    }\r\n    \r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
std::optional<\/span> is currently in the namespace experimental.<\/span> That will change with C++17. I use std::optional<\/span> in the function getFirst<\/span> (line 7). getFirst<\/span> returns the first element if it exists (line 8). You will get a std::optional<int> object (line 9) if not. I use in the main function two vectors. The calls get first<\/span> in lines 17 and 27 return the std::optiona<\/span>l objects. In the case of myInt<\/span> (line 19), the object has a value; in the case of myEmptyInt<\/span> (Zeile 29), the object has no value. Now I can display the value of myInt<\/span> (lines 20 – 22). The method value_or<\/span> in lines 22 and 30 returns the value or a default value. This is because std::optional<\/span> has a value. <\/span><\/p>\n
 <\/p>\n
The screenshot shows the output of the program using the online compiler at cppreference.com<\/p>\n
\"optional\"<\/p>\n<\/p>\n
Extended futures<\/h2>\n
Modern c++ supports tasks.<\/p>\n
 \"tasksEng\"<\/p>\n
 <\/p>\n
Tasks are pairs of  std::promise<\/span> and std::future <\/span>objects connected by a channel. Both communication endpoints may exist in different threads. The std::promise<\/span> (sender) pushes its value into the channel for which the std::future (receiver) is waiting. The sender can push a value, a notification, or an exception into the channel. I’ve written a few posts about tasks. Here are the details:  Tasks<\/a>.<\/p>\n
The easiest way to create a promise is to use the function std::async<\/a>. std::async<\/span> behaves like an asynchronous function call.<\/p>\n
\n
int<\/span> a= 2000\r\nint<\/span> b= 11;\r\nstd::future<int<\/span>> sum= std::async([=]{ return<\/span> a+b; });\r\nstd::cout << sum.get() << std::endl;\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The call std::async performs more actions. First, it creates the communication endpoints’ promise and future; second, it connects them via a channel. The lambda function [=]{ return a+b;}<\/span> is the work package of the promise. It captures arguments a and b from their defining context. The C++ run time decides if the promise will run in the same or a different thread. Criteria for its decision may be the size of the work package, the load of the system, or the number of cores.<\/p>\n
The future calls sum.get()<\/span> to get the value from the promise. You can only once call sum.get().<\/span> If the promise is not made, the get call will block.<\/p>\n
Tasks provide similar and safer handling of threads because they have no shared state that has to be protected. Therefore, race conditions are not possible, and deadlocks are much rarer. But, the C++11 implementation of futures has a big disadvantage. The composition of std::future<\/span> objects is not possible. This will not hold true for the extended futures of C++20.<\/p>\n
The table shows the functions for extended futures.<\/p>\n
\"futureImprovementEng\"<\/p>\n
Here are a few code snippets from proposal n3721.<\/a><\/p>\n
 <\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16<\/pre>\n<\/td>\n
\n
future<int<\/span>> f1= async([]() {return<\/span> 123;});\r\n\r\nfuture<string> f2 = f1.then([](future<int<\/span>> f) {\r\n     return<\/span> f.get().to_string(); \r\n});\r\n\r\nfuture<int<\/span>> futures[] = {async([]() { return<\/span> intResult(125); }), \r\n                         async([]() { return<\/span> intResult(456); })};\r\n\r\nfuture<vector<future<int<\/span>>>> any_f = when_any(begin(futures), end(futures));\r\n\r\n\r\nfuture<int<\/span>> futures[] = {async([]() { return<\/span> intResult(125); }), \r\n                         async([]() { return<\/span> intResult(456); })};\r\n\r\nfuture<vector<future<int<\/span>>>> all_f = when_all(begin(futures), end(futures));\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
The future f2<\/span> in line 3 is ready if the future f2<\/span> is ready. You can enlarge the chain of futures:  f1.then(…).then(…).then(…).<\/span> The future any_f<\/span> in line 10 becomes ready if any of its futures become ready. On the contrary, the future all_f<\/span> in line 16 becomes ready if all its futures become ready.<\/p>\n
One question is still not answered. What have futures in common with functional programming? A lot! The extended futures are a monad. I explained in the post Pure Functions<\/a> the idea of monads. The key idea of a monad is that a monad encapsulates a simple type in an enriched type and supports the compositions of functions on these enriched types. Therefore, the monad needs a function to lift the simple type into an enriched one. Additionally, a monad needs a function that empowers them to compose functions on enriched types. This job is for the functions make_ready_future, then,<\/span> and future<future<T>>. make_ready_future <\/span>maps a simple type into an enriched type, a so-called monadic value. This function is called identity and has the name return<\/span> in Haskell. The two functions then and future<future<T>><\/span> are equivalent to the bind <\/span>operator in Haskell. The bind<\/span> operator’s job is to transform one monadic value into another monadic value. bind<\/span> is the function composition in a monad. <\/p>\n
Thanks to the method when_any<\/span> std::future<\/span> even becomes a Monad Plus<\/a>. A Monad Plus requires from its instances that they are monads and have an operator msum.<\/span> Therefore, std::future<\/span> supports a kind of addition operation in C++20.<\/p>\n
If you want to know the details, you should read the excellent blog<\/a> of Bartosz Milelweski and watch his video:  “C++17: I See a Monad in Your Future!”.<\/p>\n
What’s next?<\/h2>\n
In my post Recursion, List Manipulation, and Lazy Evaluation<\/a>, I wrote: The story about lazy evaluation in C++ is quite short. But I made my conclusion without templates. Thanks to the CRTP idiom and expression templates C++ is lazy. Therefore, I will write about the infamous CRTP idiom in the next post.<\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Monads in C++? What a strange name for a post. But it’s not so strange. With std::optional, C++17 gets a monad. The ranges library from Eric Niebler and the extended futures are also monads. For both, we can hope for in C++20.<\/p>\n","protected":false},"author":21,"featured_media":5172,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[365],"tags":[508,510,482],"class_list":["post-5174","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-functional","tag-haskell","tag-monads","tag-outdated"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5174","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=5174"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5174\/revisions"}],"predecessor-version":[{"id":6889,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5174\/revisions\/6889"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5172"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5174"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5174"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5174"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}