话说模式匹配(5) for表达式中的模式匹配

在for表达式中

for(x <- collection) { balabala } 

直觉上以为 x 就是个用于迭代每一个元素的局部变量。

我们看一些例子:

scala> for(i <- List(1,2,3) ) {println(i)}

// 看看语法树  
scala> tb.parse("for(i <- List(1,2,3) ) {println(i)}")
res2: tb.u.Tree = List(1, 2, 3).foreach(((i) => println(i)))

再多一点花样,变量绑定:

scala> tb.parse("for(i@2 <- List(1,2,3) ) {println(i)}")
res3: tb.u.Tree =
    List(1, 2, 3).withFilter(((check$ifrefutable$1) => check$ifrefutable$1: @scala.unchecked match {
        case (i @ 2) => true
        case _ => false
     })).foreach(((x$1) => x$1: @scala.unchecked match {
    case (i @ 2) => println(i)
}))

将i绑定到常量模式2上,List(1,2,3)中只有2能匹配

下一个例子:

// 过滤出女性的名字
scala> for ((name,"female") <- Set("wang"->"male","zhang"->"female") ) print(name)
zhang

会在两个点做模式匹配,第一个点是从Set中过滤符合条件的元素时,第二个点是对过滤后的集合迭代执行后续逻辑时。

scala> tb.parse("for ((name,\"female\") <- Set(\"wang\"->\"male\",\"zhang\"->\"female\") ) print(name)")
res5: tb.u.Tree =
Set("wang".$minus$greater("male"), "zhang".$minus$greater("female")).withFilter(((check$ifrefutable$2) => check$ifrefutable$2: @scala.unchecked match {
    case scala.Tuple2((name @ _), "female") => true
    case _ => false
})).foreach(((x$2) => x$2: @scala.unchecked match {
    case scala.Tuple2((name @ _), "female") => print(name)
}))

同样,还可以类型模式在从集合过滤时按类型条件。

scala> for((k,v:Int) <- List(("A"->2),("B"->"C"))) {println(k)}
A

话说模式匹配(4) 赋值语句与模式匹配

先抛个问题,下面的语句是否都合理(编译通过),哪些会引起模式匹配?

scala> val a = 100 
scala> val A = 100 
scala> val a@b = 100
scala> val (a,b) = (100,200)
scala> val (a,B) = (100,200)    //第二个变量大写
scala> val Array(a,b) = Array(100,200)
scala> val Array(a,B) = Array(100,200) 

scala> object Test { val 2 = 2 } 
scala> object Test { val 2 = 3 } 

我们先看看其他语言(对scala有影响的)有关赋值语句的定义:

1) 在 ML 语言里,对赋值语句的定义:
val P = E

表示定义了模式P中的变量,并赋予它们表达式E中相应的值。

2) 在Erlang中等号 = 表示一个模式匹配操作

在这两种语言中,赋值语句都明确的定义为模式匹配,那么scala中,所有的赋值语句是否都是模式匹配呢?
尤其scala可以说在函数式风格上与ML(及其家族)语言有某种血缘,在这一点上是否也与ML完全一致呢?

先分析一下上面的每条赋值语句:val a = 100val A = 100是直观且没有歧义的。

val a@b = 100 是什么意思?回忆一下第一篇里讲过的“变量绑定模式”,当时的例子有点复杂,重新理解一下:

//给"hello"字符串对象用v1这个变量名
scala> "hello" match { case v1 => println(v1) }

//变量绑定模式,把变量v2 绑定在v1这个模式上
scala> "hello" match { case v2@v1 => println(v2) }

上面的例子中,第一行中v1是个变量模式。 第二行中v2是一个新的变量,只有在v1这个模式匹配成功的情况下,才会把自己绑定到v1上,而v1因为是一个变量模式,它总能匹配成功,所以这里v2也会绑定到”hello”对象上。变量绑定模式通常不会这么使用,更多用在绑定到一个复合结构的模式上,如:

scala> List(1,List(2,3)) match { case List(_, x@List(2,_*)) => println(x.size) }
2

把变量x绑定到了嵌套的 List(2,3) 这个对象上

但赋值语句val a@b = 100 跟上面的有关系么?我们通过ToolBox看看它”脱糖”后的语法树:

scala> tb.parse("val a@b=100")
res13: tb.u.Tree =
{
    <synthetic> private[this] val x$3 = 100: @scala.unchecked match {
        case (a @ (b @ _)) => scala.Tuple2(a, b) //这一句
    };
    val a = x$3._1;
    val b = x$3._2
}

有注释的那一句里面把a,b两个局部变量绑定到通配符”_”上,而这个通配符模式case _ => 可以匹配任何对象,所以相当于把a,b两个变量绑定到了100这个对象上,并产生了一个二元组记录这两个局部变量值。最终把二元组里的值分别赋给了我们定义的a,b两个变量。

接下来的val (a,b) = (100,200) 这个赋值也容易理解,把二元组里的值分别赋给a,b两个变量么,也是经过模式匹配的么?继续用ToolBox分析:

scala> tb.parse("val (a,b)=(100,200)")
res14: tb.u.Tree =
{
    <synthetic> private[this] val x$4 = scala.Tuple2(100, 200): @scala.unchecked match {
        case scala.Tuple2((a @ _), (b @ _)) => scala.Tuple2(a, b)
    };
    val a = x$4._1;
    val b = x$4._2
}

看到了,是一个构造器模式与变量绑定模式的混合模式匹配。

再下一个val (a,B) = (100,200) 这个与上一个有区别么?回顾一下第一篇里讲到的“常量模式”:当变量大写时将被对待为常量模式,也就是说 大写B 和上面的 小写b 是两种不同的模式!!

scala> tb.parse("val (a,B)=(100,200)")
res15: tb.u.Tree =
val a = scala.Tuple2(100, 200): @scala.unchecked match {
    case scala.Tuple2((a @ _), B) => a
} 

大写B在这里当作常量来解析,但又找不到B这个变量(除非之前有定义过),就报错了:

scala> val (a,B) = (100,200)
<console>:8: error: not found: value B
   val (a,B) = (100,200)
          ^

后边两个Array的赋值语句与这两个类似,小括号写法只是元组(Tuple)的语法糖而已。

最后,真正有趣,且会让新手崩溃的情况 object Test { val 2 = 2 } 为什么这个编译和初始化都没问题?

scala> object Test { val 2 = 2 }
defined module Test

scala> Test
res16: Test.type = Test$@3042dc22

简直逆天,难道这个背后也与模式匹配有关系么?

scala> tb.parse(" object Test { val 2 = 2 }")
res0: tb.u.Tree =
object Test extends scala.AnyRef {
    def <init>() = {
        super.<init>();
        ()
    };
    <synthetic> private[this] val x$1 = 2: @scala.unchecked match {
        case 2 => ()
    }
}

确实又是一个常量模式匹配,2匹配2,成功。

同理,下一个 object Test { val 2 = 3 } 也是个常量模式匹配,但为何明显不匹配,却可以编译时成功,而运行时时才报错呢?

scala> object Test { val 2 = 3 }
defined module Test

scala> Test
scala.MatchError: 3 (of class java.lang.Integer)
    at Test$.<init>(<console>:8)

这是因为object 是惰性初始化的原因(lazy),如下:

// 对下面的单例
object Test { val a = 2 }

$ scalac -Xprint:jvm A.scala
package <empty> {
  object Test extends Object {
    private[this] val a: Int = _;
    <stable> <accessor> def a(): Int = Test.this.a;
    def <init>(): Test.type = {
        Test.super.<init>();
        Test.this.a = 2;  //在初始化时才对成员赋值
        ()
    }
  }
}

在对多个变量赋值,或变量中有@符合,导致模式匹配还好理解,但”2=2″也引起模式匹配就会让我产生疑问:
是否所有的赋值语句都是模式匹配?

为了验证,通过编译选项查看val a=2 这样对单个变量的赋值却没有看到模式匹配。
另外,如果单个变量也是模式匹配,为何大写字母val A=2没问题?假设对单个变量赋值也是模式匹配,那岂不无法定义大写的变量了;肯定是有区别的,但又怎么区分的?

我最初遇到这个困惑,在邮件列表里问了这个问题,得到了一些回复,并且有人给了一个老帖子链接说早就讨论过val 1=2这个话题了:http://thread.gmane.org/gmane.comp.lang.scala.user/44036

在那个帖子里,martin也回复了为何 val 1=2是模式匹配,并且为何不把这种情况作为错误给修复掉:

A value definition is of the form

val <pattern> = <expression> // 这个同ML和Erlang语言
1 is a <pattern>

There is one edge case:
If the pattern is a single variable (upper or lower case or backquoted), then it is always treated as a variable, not a constant. Otherwise, there would be no way to define such a value.

只有一种边缘情况:如果模式是一个单独的变量(大写、小写、或用反引号引起来的),那么它总被当作变量,而非常量。否则就没法定义这样的一个值。

所以1=2, "a"="b" 这样的赋值语句虽然是一个变量,但变量名称不符合上面的约束,产生了模式匹配。至于为何不修复这个问题(直接在编译时报错),也可以从这个帖子的线索中找到原因。

话说模式匹配(3) 模式匹配的核心功能是解构!

http://www.artima.com/scalazine/articles/pattern_matching.html
这篇文章是odersky谈scala中的模式匹配的一段对话,我做了部分片段翻译(不是连贯的):

模式可以嵌套,就像表达式嵌套,你可以定义深层的模式,通常一个模式看起来就像一个表达式。它基本上就是同一类事情。它看起来像一个复杂的对象树构造表达式,只是漏掉了new关键字。事实上在scala当你构造一个对象,你不需要new关键字
然后你可以在一些地方用变量做站位符替代对象树上实际的东西。

本质上,当你需要通过外部来构造对象图,模式匹配是必要的,因为你不能对这些对象添加方法。
有很多场景的例子,XML是一个,所有解析过的数据落入不同的分类。举例,一个标准的场合是当你用编译器解析抽象语法树的时候模式匹配是必要的。

解构对象 (De-constructing objects)

Bill Venners: 你说模式像表达式,但它更像“逆表达式”,不同于插入值并得到结果(构造一个对象的过程),你放入一个值,当它匹配,一串值弹出来。

Martin Odersky: 是的,它确实是反向构造,我可以通过嵌套的构造器来构造对象。我有一个方法一些参数,通过这些参数可以构造出复杂的对象结构。模式匹配正好相反,它从一个复杂的对象结构中抽出原来用于构造这个对象的参数

可扩展性的两个方向(Two directions of extensibility)

扩展性的另一个概念是数据结构相对固定,你不想改变它,但你想要用到的行为操作是开放的。你随时都想要添加新的操作。
典型的例子是编译器,编译器用语法树表达你的程序,只要你没有改变你的语言,语法树就不会变,一直都是同一颗树
但编译器想要这棵语法树每天改变。明天你或许想到一种新的优化在遍历树的阶段。

所以,你想采取的办法是操作定义在你的语法树外部,否则你要不断的添加新方法

这个工作正确的方向,取决于你想在那个方向扩展,如果你想要扩展新的数据,你选择经典的面向对象通过虚方法调用实现。如果你想保持数据固定,扩展新的操作,模式更适合。实际上有一个设计模式,不要和模式匹配混淆,在面向对象程序中称为“访问者模式”,也可以用面向对象的方式表达模式匹配的方式,基于虚方法委派的。

但实际中用visitor模式是非常笨重的,不能像模式匹配那样轻松的做很多事。你应该终结笨重的vistors,同时在现代虚拟机技术中也证明vistor模式远没有模式匹配有效。所有这些原因,我想应该为模式匹配定义一套规则

ps, 前段时间王垠同学在批判设计模式的一篇文章中,提到visitor模式就是模式匹配。
可以对比一下scala语言通过case class/extractor方式在语言级别支持模式匹配,与通过visitor模式来达到同样的效果时的代码差别。

话说模式匹配(2) scala里是怎么实现的?

在这篇martin和另外两位模式匹配领域专家的论文里说了模式匹配的几种实现方式,以及scala是选择哪种方式来实现的。http://lampwww.epfl.ch/~emir/written/MatchingObjectsWithPatterns-TR.pdf

我引用了里面的一些描述。
在面向对象的程序中数据被组织为一级一级的类(class),面向对象语言在模式匹配方面的问题在于如何从外部探测这个层级。

有6种实现模式匹配的方法:

  1. 面向对象的分解 (decomposition)
  2. 访问器模式 (visitor)
  3. 类型测试/类型造型 (type-test/type-cast)
  4. typecase
  5. 样本类 (case class)
  6. 抽取器 (extractor)

论文里从3个维度9个标准来对比了各种实现方式:
简明程度(框架支持、浅匹配、深匹配),维护性(表征独立、扩展性),性能(基础性能、广度和深度延展性)

比较的细节在这篇论文里有提,不一一展开。最终scala选择了采用 样本类(case class)抽取器(extractor) 来实现模式匹配。我们大致了解一下case class和extractor 是怎么回事

1)样本类(case class)

本质上case class是个语法糖,对你的类构造参数增加了getter访问,还有toString, hashCode, equals 等方法;
最重要的是帮你实现了一个伴生对象,这个伴生对象里定义了apply 方法和 unapply 方法。
apply方法是用于在构造对象时,减少new关键字;而unapply方法则是为模式匹配所服务。
这两个方法可以看做两个相反的行为,apply是构造(工厂模式),unapply是分解(解构模式)。
case class在暴露了它的构造方式,所以要注意应用场景:当我们想要把某个类型暴露给客户,但又想要隐藏其数据表征时不适宜。

2) 抽取器(extrator)

抽取器是指定义了unapply方法的object。在进行模式匹配的时候会调用该方法。
unapply方法接受一个数据类型,返回另一数据类型,表示可以把入参的数据解构为返回的数据。
比如

class A
class B(val a:A)
object TT {
    def unapply(b:B) = Some(new A)
}

这样定义了抽取器TT后,看看模式匹配:

val b = new B(new A); 
b match{ case TT(a) => println(a) }

直观上以为 要拿b和TT类型匹配,实际被翻译为

TT.unapply(b)  match{ case Some(…) => … }

它与上面的case class相比,相当于自己手动实现unapply,这也带来了灵活性。
后续会专门介绍一下extrator,这里先看一下extractor怎么实现case class无法实现的“表征独立”(representation independence)

比如我们想要暴露的类型为A

//定义为抽象类型
trait A

//然后再实现一个具体的子类,有2个构造参数
class B (val p1:String, val p2:String) extends A

//定义一个抽取器
object MM{
    //抽取器中apply方法是可选的,这里是为了方便构造A的实例
    def apply(p1:String, p2:String) : A = new B(p1,p2);

    //把A分解为(String,String)
    def unapply(a:A) : Option[(String, String)] = {
        if (a.isInstanceOf[B]) {
         val b = a.asInstanceOf[B]
         return Some(b.p1, b.p2)
        }
        None
    }
}

这样客户只需要通过 MM(x,y) 来构造和模式匹配了。客户只需要和MM这个工厂/解构角色打交道,A的实现怎么改变都不受影响。

注:

有很多的资料里在介绍case class时经常把它和函数式语言里的代数数据类对比(ADT)。严格的说Scala中的case class并不是ADT,但比较靠近,可以模拟ADT。

这篇文章中提到case class介于类继承和代数数据类型之间 http://blog.csdn.net/jinxfei/article/details/4677359

“Scala则提供了一种介于两者之间(类继承和代数数据类型),被称为条件类(case classes)的概念”

《Programming in Scala》中文版,在术语表中也有提到ADT:

通过提供若干个含有独立构造器的备选项(alternative)来定义的类型。通常可以辅助于通过模式匹配解构类型的方式。这个概念可以在规约语言和函数式语言中发现。代数数据类型在Scala中可以用样本类(case class)模拟。