Scala REPL中的递归重载语义–JVM语言

使用 Scala的命令行REPL:

def foo(x: Int): Unit = {}
def foo(x: String): Unit = {println(foo(2))}

error: type mismatch;
found: Int(2)
required: String

您似乎无法在REPL中定义重载的递归方法.我认为这是Scala REPL中的一个错误并提交了它,但它几乎立即关闭了“wontfix:我没有看到任何方式这可以支持解释器的语义,因为这两个方法必须编译一起.”他建议将方法放在一个封闭的对象中.

是否有JVM语言实现或Scala专家可以解释原因?我可以看到,如果这些方法相互调用,那将是一个问题,但在这种情况下?

或者,如果这个问题太大而且您认为我需要更多必备知识,那么是否有人有关于语言实现的书籍或网站的任何良好链接,尤其是在JVM上? (我知道约翰罗斯的博客,以及编程语言语用学这本书……但这就是它.:)

解决方法

问题是由于解释器通常必须用给定名称替换现有元素,而不是使它们超载.例如,我经常会尝试某些东西,经常创建一个名为test的方法

def test(x: Int) = x + x

稍后,让我们说我正在运行一个不同的实验,我创建另一个名为test的方法,与第一个无关:

def test(ls: List[Int]) = (0 /: ls) { _ + _ }

这不是一个完全不切实际的场景.事实上,正是大多数人使用解释器的方式,通常都没有意识到.如果解释器任意决定将两个版本的测试都保留在范围内,那么可能会导致使用测试时出现混淆的语义差异.例如,我们可能会调用test,意外地传递Int而不是List [Int](这不是世界上最不可能发生的事故):

test(1 :: Nil)  // => 1
test(2)         // => 4  (expecting 2)

随着时间的推移,解释器的根范围将变得非常混乱各种版本的方法,字段等.我倾向于让我的解释器一次打开几天,但如果允许这样的超载,我们将被迫“因为事情变得太混乱,所以经常翻译“翻译”.

它不是JVM或Scala编译器的限制,而是一个经过深思熟虑的设计决策.正如bug中所提到的,如果你在根范围之外的其他东西,你仍然可以重载.将测试方法包含在一个类中似乎是对我来说最好的解决方案.

相关文章

共收录Twitter的14款开源软件,第1页Twitter的Emoji表情 Tw...
Java和Scala中关于==的区别Java:==比较两个变量本身的值,即...
本篇内容主要讲解“Scala怎么使用”,感兴趣的朋友不妨来看看...
这篇文章主要介绍“Scala是一种什么语言”,在日常操作中,相...
这篇文章主要介绍“Scala Trait怎么使用”,在日常操作中,相...
这篇文章主要介绍“Scala类型检查与模式匹配怎么使用”,在日...