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

Question

在SML，Erlang等语言中，我们可以定义如下函数:

fun reverse [] = []
|   reverse x :: xs  = reverse xs @ [x];

我知道我们可以像这样在Scala中编写模拟代码(而且我知道，下面的代码有很多缺陷):

def reverse[T](lst: List[T]): List[T] = lst match {
  case Nil     => Nil
  case x :: xs => reverse(xs) ++ List(x)
}

但是我想知道，是否可以在Scala中编写前者的代码，也许对后者不满意。

将来实现这种语法是否有任何基本限制(我是说，真的很基本-例如，类型推断在scala中的工作方式，或者除解析器以外的其他方式)？

UPD
以下是其外观的摘要:

type T
def reverse(Nil: List[T]) = Nil
def reverse(x :: xs: List[T]): List[T] = reverse(xs) ++ List(x)

Answer 1

这实际上取决于基本的含义。

如果您真的在问“是否有技术上的障碍会阻止实现此功能”，那么我会说答案是否。您正在谈论减糖，并且您在这里的路正确。所有要做的就是将几个单独的案例基本缝合到一个单一的函数中，并且这可以仅作为预处理步骤来完成(这仅需要语法知识，而无需语义知识)。但是，为了使这一点更有意义，我将定义一些规则:

函数签名是强制性的(例如，在Haskell中，这是可选的，但是无论是一次还是分多个部分定义函数，它始终是可选的)。我们可以尝试安排没有签名的生活，并尝试从不同部分中提取签名，但是缺少类型信息将很快使我们陷入困境。一个更简单的论据是，如果我们要尝试推断隐式签名，那么我们也可以对所有方法都这样做。但是事实是，在scala中有明确的特征非常有充分的理由，我无法想象改变这一点。

所有部分都必须在同一范围内定义。首先，必须在同一文件中声明它们，因为每个源文件都是单独编译的，因此，简单的预处理程序不足以实现该功能。其次，最后我们仍然只能使用一个方法，因此将所有部分都放在同一范围内是很自然的。

此类方法无法重载(否则，我们将需要为每个部分重复签名，以便预处理器知道哪个部分属于哪个重载)

零件按照声明为

的顺序添加(缝合)到生成的match中

所以这是什么样子:

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作者实际上倾向于使语言更简单(例如，内置功能较少的情况下，尝试将某些内置功能移入库中)并添加实际上不易读的新语法有悖于简化的目标。