Monads

3 Key excerpts on "Monads"

• 

  eBook - ePub

  Hands-On Design Patterns with React Native

  Proven techniques and patterns for efficient native mobile development with JavaScript

  • Mateusz Grzesiukiewicz(Author)
  • 2018(Publication Date)
  • Packt Publishing

    (Publisher)

  Be aware that you need to avoid such simplifications if your function is not referentially transparent. Expressions such as the preceding or x() + x() * 0 are tempting gotchas.

  Whether you make any use of it or not is up to you. Also, see the Further reading section at the end of the chapter.

  Passage contains an image

  Everything but Monads

  The term monad has been infamous for many years. Not because it's an amazingly useful construct, but because of the complexity it introduces. There is also a common belief that once you understand Monads, you lose the capability to explain them.

  "In order to understand Monads, you need to first learn Haskell and Category Theory. I think this is like saying: In order to understand burritos, you must first learn Spanish." - Douglas Crockford: Monads and Gonads (YUIConf Evening Keynote) https://www.youtube.com/watch?v=dkZFtimgAcM .

  A monad is a way of composing functions despite special circumstances, such as nullable values, side-effects, computations, or just conditional execution. Such a definition of a monad makes it a context holder. That's why the monad of X is not equivalent to X. This X Before being treated as monad<X>, this X something needs to be lifted first, which simply means creation of the required context. If we do not need monad<X> anymore, we can flatten the structure to just X, which is the equivalent of losing a context.

  It's like unwrapping a present for Christmas. You are pretty sure there is a present in there, but it depends on whether you were nice throughout the year. In some rare cases of misbehavior, you may end up with the stick or lump of coal in there . This is how the Maybe<X> monad works. It may be X or nothing. It works great with nullable API values.

  Passage contains an image

  Call me Maybe

  There is one place in our code that begs for simplification. Take a look at the taskSelector:

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Soar with Haskell

  The ultimate beginners' guide to mastering functional programming from the ground up

  • Tom Schrijvers(Author)
  • 2023(Publication Date)
  • Packt Publishing

    (Publisher)

  11

  Monads

  This chapter introduces the king of the type constructor hierarchy: the monad. I see two main reasons for the prominent position and importance of Monads:

  • The first reason is an objective and pragmatic one—we can write more expressive effectful programs with Monads than we can with applicative functors. In particular, the control flow of applicative functor programs is fixed upfront before it is run. Each step in an applicative program produces a result, and these results are combined to form the final result. In contrast, the control flow of monadic programs is more flexible. The result of a monadic step can determine what the next steps to take are. In essence, we have the same flexibility in monadic programs as we do in pure programs.
  • This flexibility makes Monads the first abstraction that Haskell programmers reach when writing effectful programs. Even when the same code can be written using either the monad or the applicative function abstraction, monad abstraction is often used. This way, it takes less time to refactor the code later when it turns out the extra flexibility of Monads is needed after all. Even so, there is a trade-off to be made, as there are fewer Monads than there are applicative functors.
  • The second reason is that Monads simply have a much longer history than applicative functors. They were the first purely functional model for effects that were explored and incorporated in Haskell at the end of the 1980s and the beginning of the 1990s. They were adopted as the unique approach to IO , which we saw in Chapter 8 , Input/Output . In contrast, applicative functors were introduced much later, in 2008. By that time, Monads were already firmly established, and applicative functors had never been as widely embraced and recognized, especially not to the extent that they have become well-known outside of the Haskell community.

  If you have been going through the chapters of this book, Monads will likely be less of a revelation for you. While we did not use the word, the IO type in Chapter 8 , Input/Output was our first example of a monad. Moreover, in this chapter, we will see how Monads are a step up from applicative functors, first by looking at two examples (Maybe and State ) and then by discussing in their generality. Finally, we will review several more commonly used Monads in the standard library.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Learning Functional Programming in Go

  • Lex Sheehan(Author)
  • 2017(Publication Date)
  • Packt Publishing

    (Publisher)

  Constrained? What’s constrained? Well, that’s an overloaded term. From a framework perspective, we are constraining/quarantining our side effect causing and real-world interfacing code to this little, purposeful box. Its job is to perform the specific data mapping transformation functions that have been provided to it. If any errors occur, the framework will capture them and package the errors for us, and will ensure that they quickly travel down the Failure path until they get spit out the end of the execution pipe, where all errors for this execution chain are handled. From a data perspective, we use our type system to constrain the input to only valid data types. (If we have a division operation, we can constrain our input type to be PositiveNumbers to ensure that a divide by zero exception will never occur.) From a type class perspective, our operations are constrained by the laws of Monads.

  What operations? What laws? The operations are the sequences of tasks that we chain together to perform various operations on our data. If we start with a list of cars, we might want to transform our list by applying the following transformations:

  Filter(ByDomestic()).Map(Upgrade()).Reduce(JsonReducer())

  And finally, what do we mean by controlled? This is where the Monad shines. The Monad provides the structure for chaining the transformation operations. It provides the Success and Failure paths. Now, rather than littering our code with if err != nil error checking blocks, we can put all of our error handling logic at the end of all of the steps we need to perform for our particular use case.

  One more time: What is a Monad? A Monad is a design pattern that provides a way of chaining operations together. The bind function is what links the operations together in a chain; it takes the output from one step and feeds it into the next one.

  We can write the calls that directly use the bind operator, or we can use a sugar syntax, in a language like Haskell, which makes the compiler insert those function calls for use. But either way, each step is separated by a call to the bind function.

  Since Haskell is a fully baked pure functional programming language, we'll often refer to its FP in order to think about how we can best incorporate that method of thinking/design into our Go solutions.

  In Haskell, there are many kinds of Monads. 

  What makes each monad unique and especially useful is what it does in addition to the bind operation. We can use the following table of Monads found in Haskell as a starting point for building a package of Monads in Go:

  Sign up to read

  Learn more about book