C++Now 2017: David Sankel 'The Mathematical Underpinnings of Promises in C++'

—
—
What is the mathematical essence of a promise and how does it inform the development of a promise library in C++? This talk explores the algebraic foundation of promises and applies those concepts to the development of a promise library. This talk serves as a case study of using functional design to develop a practical library. The discussion will lead to general questions such as "How do you discover the fundamental operations for a type?" and Which
aspects of a mathematical design need modification to fit into a practical language?".

We will be touching on purity, denotational semantics, monads, laziness, and pragmatism. All abstract concepts will be adequately introduced and no background in mathematics is required. Attendees should walk away with an understanding of how functional design is put into practice and may even want to give it a whirl in their next project.
—
David Sankel is a professional software developer/architect based in the USA and an active member of the C++ Standardization Committee. His prolific software developments have included CAD/CAM, computer graphics, visual programming languages, web applications, computer vision, and cryptography. He is a frequent speaker at the C++Now conferences and is especially well known for his advanced functional programming in C++ talks. David’s interests include large-scale development, dependently typed languages, semantic domains, EDSLs, and functional reactive programming. David's current research interests include dependently typed languages, semantic domains, EDSLs, and functional reactive programming. He currently works for Bloomberg.
—
---

*--*

---

[bigolol]

thank you very much for making these available

[TimTeatro]

At 58:40, on the slide showing the operational semantics, someone asks about the ability of the semantic model to express the situation when `p2` finishes but `p1` is in the waiting state, and there is no dependency between `p1 and `p2`. Can't that be written (using your notation, plus the right-tack for conditional assertion instead of the bar) as ( <E, p1 → W> <E, p2→v1> ) ⊢ ( <E, first(p1, p2) > → <E, p2> ) ? I feel like I'm missing something fairly fundamental, but that seems to me to cover it. If p1 is in the waiting state and p2 gets a value, then first(p1, p2) should reduce to p2.

[botetescribavicentej.]

I agree with you that we need to define the minimal set of operations.
I agree also that avoiding get force a more safe interface.

Overloading then we could have the impression that we are having only one operation, but what is wrong by using different names for different meanings.
If you rename your first overload fmap and the second mbind, you don't need anymore the 3rd overload with keep.

What is the advantage to use always .then() with different kind of return types from the continuations?

BTW, I'm missing the mreturn function.

Just to remember a proposal that was not accepted