Scala's for comprehension transformation flatMap, map for the resting developer

I'm not a scala mega mind so feel free to correct me, but this is how I explain the flatMap/map/for-comprehension saga to myself!

To understand for comprehension and it's translation to scala's map / flatMap we must take small steps and understand the composing parts - map and flatMap. But isn't scala's flatMapjust map with flatten you ask thyself! if so why do so many developers find it so hard to get the grasp of it or of for-comprehension / flatMap / map. Well, if you just look at scala's map and flatMap signature you see they return the same return type M[B] and they work on the same input argument A (at least the first part to the function they take) if that's so what makes a difference?

Our plan

Understand scala's map.

Understand scala's flatMap.

Understand scala's for comprehension.`

Scala's map

scala map signature:

map[B](f:(A)=> B): M[B]

But there is a big part missing when we look at this signature, and it's - where does this A comes from? our container is of type A so its important to look at this function in the context of the container - M[A]. Our container could be a List of items of type A and our map function takes a function which transform each items of type A to type B, then it returns a container of type B (or M[B])

Let's write map's signature taking into account the container:

M[A]:// We are in M[A] context.
map[B](f:(A)=> B): M[B]// map takes a function which knows to transform A to B and then it bundles them in M[B]

Note an extremely highly highly important fact about map - it bundles automatically in the output container M[B] you have no control over it. Let's us stress it again:

map chooses the output container for us and its going to be the same container as the source we work on so for M[A] container we get the same M container only for BM[B] and nothing else!

map does this containerization for us we just give a mapping from A to B and it would put it in the box of M[B] will put it in the box for us!

You see you did not specify how to containerize the item you just specified how to transform the internal items. And as we have the same container M for both M[A] and M[B] this means M[B]is the same container, meaning if you have List[A] then you are going to have a List[B] and more importantly map is doing it for you!

Now that we have dealt with map let's move on to flatMap.

Scala's flatMap

Let's see its signature:

flatMap[B](f:(A)=> M[B]): M[B]// we need to show it how to containerize the A into M[B]

You see the big difference from map to flatMap in flatMap we are providing it with the function that does not just convert from A to B but also containerizes it into M[B].

why do we care who does the containerization?

So why do we so much care of the input function to map/flatMap does the containerization into M[B] or the map itself does the containerization for us?

You see in the context of for comprehension what's happening is multiple transformations on the item provided in the for so we are giving the next worker in our assembly line the ability to determine the packaging. imagine we have an assembly line each worker does something to the product and only the last worker is packaging it in a container! welcome to flatMap this is it's purpose, in map each worker when finished working on the item also packages it so you get containers over containers.

The mighty for comprehension

Now let's looks into your for comprehension taking into account what we said above:

The rules are the if we have multiple <- they translate to flatMap except for the last one.

As f <- mkMatcher(pat) is first in sequence (think assembly line) all we want out of it is to take f and pass it to the next worker in the assembly line, we let the next worker in our assembly line (the next function) the ability to determine what would be the packaging back of our item this is why the last function is map.

The last g <- mkMatcher(pat2) will use map this is because its last in assembly line! so it can just do the final operation with map( g => which yes! pulls out g and uses the f which has already been pulled out from the container by the flatMap therefore we end up with first:

mkMatcher(pat) flatMap (f // pull out f function give item to next assembly line worker (you see it has access to f, and do not package it back i mean let the map determine the packaging let the next assembly line worker determine the container. mkMatcher(pat2) map (g => f(s) ...)) // as this is the last function in the assembly line we are going to use map and pull g out of the container and to the packaging back, its map and this packaging will throttle all the way up and be our package or our container, yah!

For each topic we have a status column, use it for our own to track the status of your progress in the study this topic. In addition, we have a tutorial column where we point to the best video or tutorial for study this topic, this doc is a work in progress, please let us know for any suggestion.

Now by far the best book (although I think I could have created a better version) for studying for programing interviews is: "Cracking The Coding Interview"

Remember that actors interact only using message passing. In order to check actors behavior you can do it through the messages sent to them and back from them. So how do you test actors? You send them messages :)
To test actors that communicate only with messages, you need to send it a message and get reply back and check it.
akka has a TestProbe valp=TestProbe(); // record incoming messages in queue so you can assert and verify them.
Creating actor system for tests: implicitvalsystem=ActorSystem("TestSys") valtoggle= system.actorOf(Props[Toggle]) // this is the actor we are going to test.valp=TestProbe() // this is the test client actor which will record the messages.
p.send(toggle, "How are you") // probe --> tested actor: how are you?
p.exepectMsg("happy") // assert result is happy.
To have the probe actor created for you: newTestKit(ActorSystem("TestSys")) withImplicitSender { // we are in probe actor.valtoggle= system.actorOf(Props[Toggle…

You see it's much easier than you think there exists a limit set of rules you should apply to most of the programming interview questions which involves algorithms and data structures. I have prepared a summary of them for you, just read below and get your tips for today.When you have no clue / Under panic attack => Brute Force!

If you don't have a clue, brute force the fu**** question! In most cases the question you are presented with has a brute force solution. Mention clearly that you are brute forcing it and say that the time complexity is O(n^2) or whatever it is. Then think where do you waste time in your brute force solution, try to improve that part, in many cases, this will get you closer to the actual answer.

By brute forcing you get to be familiarize with the problem better. A common theme for brute forcing means you are going to have a for loop inside a foor loop something like the below, so it's great to get familiarize with common bruteforcing snippets,…

We are a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for us to earn fees by linking to Amazon.com and affiliated sites.