monad

Another Scala nested Option + flatMap example

After yesterday’s Scala nested Option + flatMap/for example, here’s another example of plowing through nested Options with flatMap. First, start with some nested options:

val o1 = Option(1)
val oo1 = Option(o1)
val ooo1 = Option(oo1)

Here are those same three lines, with the data type for each instance shown in the comments:

This website is a little one-man operation. If you found this information helpful, I’d appreciate it if you would share it.

Why Haskell has monads

“If it wasn’t for the problem of how to sequence input-output actions correctly, monads probably wouldn’t have appeared in Haskell. But once it was appreciated what they could do, all kinds of other uses quickly followed.”

~ Thinking Functionally with Haskell, Richard Bird

Scala: Handling nested Options with flatMap and for

Summary: In this article I show a couple of ways to extract information from optional fields in your Scala domain models. This example is a little contrived, but if you have a situation where one Option instance contains one or more other Options, this article may be helpful.

There are times when you’re creating your domain model when it makes sense to use optional fields in your case classes. For instance, when you model an Address, the “second street address” isn’t needed for all people, so making it an optional field makes sense:

This website is a little one-man operation. If you found this information helpful, I’d appreciate it if you would share it.

Scala 2.12: Either is biased, implements map and flatMap

While reading the excellent Scala/FP book, Advanced Scala with Cats, I was just reminded that Scala’s Either class was redesigned in Scala 2.12. Prior to 2.12, Either was not biased, and didn’t implement map and flatMap methods. As the image from the book shows, Either is redesigned in 2.12 to include those methods, so it can now be used in Scala for-expressions as shown.

(I write about biasing in my book, Learning Functional Programming in Scala.)

This is a page from my book, Functional Programming, Simplified

Goals, Part 2: Concrete Goals of This Book

After I released Version 0.1.2 of this book, I realized that I should state my goals for it more clearly. I don’t want you to buy or read a book that doesn’t match what you’re looking for. More accurately, I don’t want you to be disappointed in the book because your expectations are different than what I deliver. Therefore, I want to state some very clear and measurable goals by which you can judge whether or not you want to buy this book.

This is a page from my book, Functional Programming, Simplified

Disadvantages of Functional Programming

“People say that practicing Zen is difficult, but there is a misunderstanding as to why.”

Shunryu Suzuki,
Zen Mind, Beginner’s Mind

In the last chapter I looked at the benefits of functional programming, and as I showed, there are quite a few. In this chapter I’ll look at the potential drawbacks of FP.

Just as I did in the previous chapter, I’ll first cover the “drawbacks of functional programming in general”: