是否有任何基本限制,阻止Scala实现模式匹配功能？

如果你真的问“是否有技术showstopper将阻止实现这个功能”，那么我会说答案是否定的。你在说脱俗，你在这里正确的轨道上。所有要做的就是将几个分离案例基本上划分成一个单一的函数，这可以作为一个预处理步骤来完成(这只需要语法知识，不需要语义知识)。但是，为了甚至有道理，我会定义一些规则：

>函数签名是必需的(例如，在Haskell中，这将是可选的，但始终是可选的，无论是一次还是几个部分定义函数)。我们可以尝试安排没有签名的生活，尝试从不同的部分提取它，但缺少类型信息将很快到我们的字节。一个更简单的论据是，如果我们尝试推断一个隐式签名，那么我们也可以为所有的方法做。但事实是，在scala中有明确的特征有很好的理由，我无法想象会改变。
>所有零件必须在相同的范围内定义。首先，它们必须声明在同一个文件中，因为每个源文件都是单独编译的，因此一个简单的预处理器将不足以实现该功能。第二，我们最终还是以一种单一的方法，所以把所有的部件都放在同一个范围内是很自然的。
>这种方法不可能重载(否则我们需要为每个部分重复签名，这样预处理程序知道哪个部分属于哪个重载)
>按照声明的顺序将零件添加(拼接)到生成的匹配中

所以这里是如何看起来像：

def reverse[T](lst: List[T]): List[T] // Exactly like an abstract def (provides the signature)
// .... some unrelated code here...
def reverse(Nil) = Nil
// .... another bit of unrelated code here...
def reverse(x :: xs ) = reverse(xs) ++ List(x)

哪些可以简单地转化为：

def reverse[T](list: List[T]): List[T] = lst match {
  case Nil     => Nil
  case x :: xs => reverse(xs) ++ List(x)
}
// .... some unrelated code here...
// .... another bit of unrelated code here...

很容易看出，上述转换是非常机械的，可以通过操纵源AST(由接受这个新结构的稍微修改的语法产生的AST)，并将其转换成目标AST(由AST生成的AST标准scala语法)。
??然后我们可以照常编译结果。

所以你去，通过一些简单的规则，我们可以实现一个预处理器，完成所有的工作来实现这个新功能。

如果根本就是你问“有没有什么可以使这个功能不合适的地方”，那么可以说这并不是非常scala。但更重要的是，它并没有给桌面带来太大的影响。 Scala作者实际上倾向于使语言更简单(因为内置功能较少，尝试将一些内置功能转移到库中)，并添加了一个不太可读的新语法违反了简化的目标。