Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Monadic Computation in Swift. Why?

Monadic Computation in Swift. Why?

Monadic Computation comes from Functional Programming which helps write composable functions while preserving failure context/side effects and provide better abstraction. Swift although not a functional programming language, can express monadic computations elegantly and can solve all the above-mentioned problems.

In the talk, I will show why do we need Monadic Computations and how we can implement in Swift. I will share real use case of monadic computations and how our team at Zalando is using this concept. There will be a short live coding to demonstrate that Monadic Computation can be expressed elegantly in Swift.

Vijaya Prakash Kandel

November 25, 2017
Tweet

More Decks by Vijaya Prakash Kandel

Other Decks in Programming

Transcript

  1. 2

  2. 6 World full of failing cases (PROBLEM) Verify Monad propagates

    error and composes 2 Programming Paradigms Deducing answer from Monad Coding the Monad TABLE OF CONTENTS
  3. 10 A simple game: MAD.A.DAM 1. M: Multiply input to

    a random Int 2. A: Add input to a random Int 3. D: Divide input by a random Int 4. Assume Swift doesn’t have Optional Perform: MAD.A.DAM on a dice roll input.
  4. 29 RESULT MONAD T map flatMap T -> U U

    T -> U U Monad is a Contextual Type that provides linear binding and composition along with error propagation.
  5. 31 RESULT MONAD T map flatMap T -> U U

    T -> U U Optional<T> is a monad. That is why we can chain stuff together. - map() - flatMap()
  6. 32 RESULT MONAD T map flatMap T -> U U

    T -> U U Collection<T> is a monad. - map() - flatMap()
  7. 33 RESULT MONAD T map flatMap T -> U U

    T -> U U Swift Try/Catch in principle can be implemented in terms of a Result Monad.
  8. 43 Promise / Future / Deferred / IO :: Monad

    aTask: ( ( (T) -> Void)? -> Void )? T aTask T
  9. 44 Promise / Future / Deferred / IO :: Monad

    aTask: ( ( (T) -> Void)? -> Void )? aTask T then/map T -> U aTask aTask T U T -> U
  10. 45 Promise / Future / Deferred / IO :: Monad

    aTask: ( ( (T) -> Void)? -> Void )? aTask T bind/ flatMap T -> Promise<U> aTask aTask T U T -> U
  11. 46 Promise / Future / Deferred / IO :: Monad

    aTask aTask T U Evaluate and finally call into outer (U -> Void) By intending to evaluate the inner block and calling into outer block with eventual value; we unpack a promise. None of the Pomise are evaluated unless someone calls `execute()` on the outermost layer. Thereby guarantee of order of execution is applied.
  12. 54 A good programmer is someone who looks both ways

    before crossing a one-way street.” — Doug Linder
  13. 55 References 1. Monad Research Paper http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baast ad.pdf 2. Railway

    Oriented Programming https://fsharpforfunandprofit.com/rop/ 3. Dr. Bartosz Category theory lecture https://www.youtube.com/user/DrBartosz/videos 4. My blog for more detailed explanation https://kandelvijaya.com/2017/08/13/promisein30lines/ 5. Promise<T> from the talk https://github.com/kandelvijaya/MPromise 6. Result<T> from the talk https://github.com/kandelvijaya/ResultType
  14. This presentation and its contents are strictly confidential. It may

    not, in whole or in part, be reproduced, redistributed, published or passed on to any other person by the recipient. The information in this presentation has not been independently verified. No representation or warranty, express or implied, is made as to the accuracy or completeness of the presentation and the information contained herein and no reliance should be placed on such information. No responsibility is accepted for any liability for any loss howsoever arising, directly or indirectly, from this presentation or its contents. DISCLAIMER 56