Questions tagged «pattern-matching»

4
模式匹配是惯用的类型还是不良的设计?
似乎F#代码经常针对类型进行模式匹配。当然 match opt with | Some val -> Something(val) | None -> Different() 似乎很常见。 但是从OOP的角度来看,这看起来非常像基于运行时类型检查的控制流,通常会对此皱眉。要说明,在OOP中,您可能更喜欢使用重载: type T = abstract member Route : unit -> unit type Foo() = interface T with member this.Route() = printfn "Go left" type Bar() = interface T with member this.Route() = printfn "Go right" 这肯定是更多代码。OTOH,在我的OOP-y看来,它具有结构上的优势: …

1
Clojure与Scala中的模式匹配
这两种语言的模式匹配之间的主要区别是什么?我不是在指语法,而是功能,实现细节,用例范围和必要性。 Scala应用程序(例如Lift和Play)自豪地谈到了语言模式匹配能力。另一方面,Clojure具有一个库core.match,并内置了解构功能,该功能似乎也很强大。 *注:之所以被问到这个问题,是因为我看到了一篇博客文章,其中的一个程序员作为实验,使用Scala和Clojure构建了一个Lisp解释器。他说,克洛瑞尔(Clojure)比赛在经过一定长度后就中断了,但无法解释原因,但我真的很想知道。您可以在以下位置找到此帖子:http : //www.janvsmachine.net/2013/09/writing-simple-lisp-interpreter-in-clojure.html

2
为什么Scala编译器不能为未密封的类/特征给出模式匹配警告?
如果我使用未密封的trait或abstract class在Scala中使用模式匹配,我想知道,编译器是否不知道在编译时针对该特定模式匹配,可以使用此特性/类的哪些可能的实现?所以,如果这样做,会不给模式匹配的警告,即使是在trait/ abstract class不密封,因为他知道哪些类型可以被使用,通过检查所有可能的依赖性/进口? 例如,如果我有一个,Option[A]并且我只为Some[A]但不为进行模式匹配None,则编译器会抱怨,因为Option是密封的。 如果编译器无法知道/解决该问题,那为什么不呢?如果编译器(理论上)可以做到这一点,那么在Scala中不使用它的原因是什么?还有其他支持这种行为的语言吗?
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.