与flatMap / Map转换的理解混淆

我似乎并不了解Map和FlatMap。 我不明白的是,理解是一个嵌套调用map和flatMap的序列。 以下示例来自Scala中的函数式编程

def bothMatch(pat:String,pat2:String,s:String):Option[Boolean] = for { f <- mkMatcher(pat) g <- mkMatcher(pat2) } yield f(s) && g(s) 

翻译成

 def bothMatch(pat:String,pat2:String,s:String):Option[Boolean] = mkMatcher(pat) flatMap (f => mkMatcher(pat2) map (g => f(s) && g(s))) 

mkMatcher方法定义如下:

  def mkMatcher(pat:String):Option[String => Boolean] = pattern(pat) map (p => (s:String) => p.matcher(s).matches) 

模式方法如下:

 import java.util.regex._ def pattern(s:String):Option[Pattern] = try { Some(Pattern.compile(s)) }catch{ case e: PatternSyntaxException => None } 

如果有人能够在这里使用map和flatMap的基本原理,那将是非常棒的。

TL; DR直接进入最后的例子

我会尽力回顾

定义

理解是一种语法快捷方式,以便于阅读和理解的方式将flatMapmap结合起来。

让我们稍微简化一下,并假定提供上述两种方法的每个class都可以称为monad ,我们将使用符号M[A]表示具有内部typesAmonad

例子

一些常见的单子

  • List[String]在哪里
    • M[_]: List[_]
    • A: String
  • Option[Int]其中
    • M[_]: Option[_]
    • A: Int
  • Future[String => Boolean]其中
    • M[_]: Future[_]
    • A: String => Boolean

地图和flatMap

定义在通用monad M[A]

  /* applies a transformation of the monad "content" mantaining the * monad "external shape" * ie a List remains a List and an Option remains an Option * but the inner type changes */ def map(f: A => B): M[B] /* applies a transformation of the monad "content" by composing * this monad with an operation resulting in another monad instance * of the same type */ def flatMap(f: A => M[B]): M[B] 

例如

  val list = List("neo", "smith", "trinity") //converts each character of the string to its corresponding code val f: String => List[Int] = s => s.map(_.toInt).toList list map f >> List(List(110, 101, 111), List(115, 109, 105, 116, 104), List(116, 114, 105, 110, 105, 116, 121)) list flatMap f >> List(110, 101, 111, 115, 109, 105, 116, 104, 116, 114, 105, 110, 105, 116, 121) 

expression

  1. expression式中使用<- symbol的每一行都被转换为一个flatMap调用,除了最后一行被转换为一个结束map调用,其中左侧的“bound symbol”作为parameter passing给参数函数(我们之前称之为f: A => M[B] ):

     // The following ... for { bound <- list out <- f(bound) } yield out // ... is translated by the Scala compiler as ... list.flatMap { bound => f(bound).map { out => out } } // ... which can be simplified as ... list.flatMap { bound => f(bound) } // ... which is just another way of writing: list flatMap f 
  2. 只有一个<-的expression式被转换为map调用,expression式作为parameter passing:

     // The following ... for { bound <- list } yield f(bound) // ... is translated by the Scala compiler as ... list.map { bound => f(bound) } // ... which is just another way of writing: list map f 

现在到了

正如你所看到的, map操作保留了原始monad的“形状”,所以yieldexpression式也是如此: List保持一个List ,其内容通过yield的操作转换

另一方面, for中的每个装订线只是连续monads的组合,为了保持单个“外部形状”,必须将其“拼合”

假设每一个内部绑定都被转换成一个map调用,但是右边的是相同的A => M[B]函数,那么最终会得到一个M[M[B]]理解。
整个语法的目的是容易“扁平化”连续的一元运算的连接(即“提升”一个单值forms的值的操作: A => M[B] ),并添加一个final map操作可能会进行一个结论性的转换

我希望这解释了翻译select背后的逻辑,这是以机械方式应用的,即: n flatMap通过一个map调用结束的嵌套调用。

一个人为的例子
意思是显示for语法的performance力

 case class Customer(value: Int) case class Consultant(portfolio: List[Customer]) case class Branch(consultants: List[Consultant]) case class Company(branches: List[Branch]) def getCompanyValue(company: Company): Int = { val valuesList = for { branch <- company.branches consultant <- branch.consultants customer <- consultant.portfolio } yield (customer.value) valueList reduce (_ + _) } 

你能猜到valuesList的types吗?

正如已经说过的那样, monad的形状是通过理解来保持的,所以我们从company.branchesList开始,并且必须以List结束。
内部types改变,并由yieldexpression式确定:which is customer.value: Int

valueList应该是一个List[Int]

其基本原理是链接作为一个好处的monadic操作,适当的“快速失败”的error handling。

这其实很简单。 mkMatcher方法返回一个Option (这是一个Monad)。 mkMatcher操作mkMatcher的结果是NoneSome(x)

mapflatMap函数应用于None始终返回None – 作为parameter passing给mapflatMap函数不会被评估。

因此,在你的例子中,如果mkMatcher(pat)返回None,那么应用到它的flatMap将返回一个None (第二个mkMatcher(pat2)操作mkMatcher(pat2)将不会被执行),最终的map将再次返回一个None 。 换句话说,如果理解中的任何一个操作返回一个无,你就有一个快速失败的行为,其余的操作不会被执行。

这是error handling的一元风格。 命令式使用exception,基本上是跳转(到catch子句)

最后一点: patterns函数是一种将命令式error handling( trycatch )“翻译”为使用Option的一元式error handling的典型方法

这可以被转换为:

 def bothMatch(pat:String,pat2:String,s:String):Option[Boolean] = for { f <- mkMatcher(pat) // for every element from this [list, array,tuple] g <- mkMatcher(pat2) // iterate through every iteration of pat } yield f(s) && g(s) 

运行这个更好的看法如何扩大

 def match items(pat:List[Int] ,pat2:List[Char]):Unit = for { f <- pat g <- pat2 } println(f +"->"+g) bothMatch( (1 to 9).toList, ('a' to 'i').toList) 

结果是:

 1 -> a 1 -> b 1 -> c ... 2 -> a 2 -> b ... 

这类似于flatMap – 通过pat每个元素循环,并且foreach元素mapmappat2每个元素

我不是一个斯卡拉mega的头脑,所以请随时纠正我,但这是我如何解释flatMap/map/for-comprehension传奇给我自己!

为了理解for comprehension和对scala's map / flatMap的翻译,我们必须采取小步骤,理解构成部分 – mapflatMap 。 但是,不是scala's flatMap只是map flatten你问自己! 如果是这样的话,为什么很多开发者会觉得很难掌握它或者for-comprehension / flatMap / map 。 那么,如果你只看scala的mapflatMap签名,你会发现它们返回相同的返回typesM[B]并且它们使用相同的input参数A (至less是它们所采用函数的第一部分)有什么区别?

我们的计划

  1. 了解斯卡拉的map
  2. 理解scala的flatMap
  3. 理解斯卡拉的for comprehension

斯卡拉的地图

斯卡拉地图签名:

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

但是当我们看这个签名的时候,有一个很大的缺失,就是 – 这个A来自哪里? 我们的容器是AtypesA所以在容器的上下文中看这个函数很重要 – M[A] 。 我们的容器可以是一个Atypes的项目List ,我们的map函数使用一个函数将Atypes的每个项目转换成Btypes,然后返回一个Btypes的容器(或M[B]

考虑到容器,我们来写地图的签名:

 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] 

注意一个关于map非常高度重要的事实 – 它自动捆绑在输出容器M[B]您无法控制它。 让我们再次强调一下:

  1. map为我们select了输出容器,并且它将和我们的源代码一样是容器,所以对于M[A]容器,我们只为B M[B]获得相同的M容器,没有别的!
  2. map为我们做这种容器化,我们只是给出一个从AB的映射,它会把它放在M[B]的框中,将它放在我们的盒子里!

你看到你没有指定如何containerize你刚刚指定的项目如何转换内部项目。 因为我们对于M[A]M[B]都有相同的容器M ,这意味着M[B]是同一个容器,这意味着如果你有List[A]那么你将有一个List[B]和更重要的是map是为你做的!

现在我们已经处理了map让我们继续前往flatMap

斯卡拉的flatMap

让我们看看它的签名:

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

在flatMap中,我们看到了从map到flatMap的巨大差异,我们提供的function不是从A to B转换A to B而是将其转换为M[B]

为什么我们关心集装箱化的人呢?

那么为什么我们如此关心map / flatMap的input函数将容器集成到M[B]还是映射本身为我们做了容器化呢?

您在for comprehension的背景下看到发生了什么事情,是for让我们的assembly线中的下一个工人能够确定包装,而在工件中提供的项目上进行了多次转换。 想象一下,我们有一条assembly线,每个工人对产品做了一些事情,只有最后一名工人将它包装在一个容器中! 欢迎来到flatMap这是它的目的,在map每个工作人员完成该项目的工作也打包它,让你的容器上的容器。

强大的理解力

现在让我们看看你的理解,考虑到我们上面所说的:

 def bothMatch(pat:String,pat2:String,s:String):Option[Boolean] = for { f <- mkMatcher(pat) g <- mkMatcher(pat2) } yield f(s) && g(s) 

我们在这里得到了什么:

  1. mkMatcher返回一个container ,容器包含一个函数: String => Boolean
  2. 规则是如果我们有多个<-他们翻译成flatMap除了最后一个。
  3. 由于f <- mkMatcher(pat)是第一个sequence (想象assembly line )所有我们想要的就是把它传递给stream水线中的下一个工人,我们让下一个工人在我们的stream水线下一个function)能够确定什么是我们的项目包装后面这就是为什么最后一个function是map
  4. 最后的g <- mkMatcher(pat2)将使用map这是因为它的最后一个在stream水线! 所以可以用map( g =>来做最后的操作map( g =>是的!拉出g并使用已经从flatMap从容器中拉出来的f ,因此我们以第一个结束:

    mkMatcher(pat)flatMap(f //把f函数给出给下一个stream水线工作者(你看它有权访问f ,不打包回来,我的意思是让映射确定包装让下一个stream水线工人确定mkMatcher(pat2)map(g => f(s)…))//因为这是assembly线中的最后一个函数,我们将使用map和pull g从容器和包装回来,它的map和这个包装会一路飙升,成为我们的包装或我们的容器,呀!

首先, mkMatcher返回一个函数,其签名是String => Boolean ,这是一个正常运行Pattern.compile(string) java过程,如pattern函数中所示。 然后,看看这一行

 pattern(pat) map (p => (s:String) => p.matcher(s).matches) 

map函数应用于pattern的结果,即Option[Pattern] ,所以p => xxx中的p => xxx就是你编译的模式。 因此,给定一个模式p ,构造一个新的函数,它接受一个strings ,并检查s与模式匹配。

 (s: String) => p.matcher(s).matches 

请注意, pvariables是绑定到编译模式。 现在,清楚的是,具有签名String => Boolean的函数是如何由mkMatcher构造的。

接下来,我们来bothMatch基于mkMatcherbothMatch函数。 为了展示bothMathch如何工作,我们首先看看这个部分:

 mkMatcher(pat2) map (g => f(s) && g(s)) 

由于我们从mkMatcher获得了一个具有签名String => BooleanmkMatcher ,在这个上下文中, g(s)等同于Pattern.compile(pat2).macher(s).matches ,如果String匹配模式pat2 。 那么f(s)怎么样,和g(s)是一样g(s) ,唯一不同的是, mkMatcher的第一个调用是使用flatMap而不是map ,为什么? 因为mkMatcher(pat2) map (g => ....)返回Option[Boolean] ,所以如果两个调用都使用map ,那么将得到一个嵌套的结果Option[Option[Boolean]] ,这不是你想要的。

Interesting Posts