Scala 能有多纯粹和懒惰？

发布于 2024-12-06 15:18:33 字数 168 浏览 6 评论 0原文

这只是“我想知道……”的问题之一。

Scala 具有不可变的数据结构和（可选）惰性 val 等。Scala

程序与完全纯粹（在函数式编程意义上）和完全惰性的程序有多接近（或者正如 Ingo 指出的那样，它是否可以足够不严格））？哪些价值观不可避免地是可变的，哪些评估不可避免地是贪婪的？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

权谋诡计 2024-12-13 15:18:33

关于惰性 - 目前，将参数传递给方法默认是严格的：

def square(a: Int) = a * a

但是您使用按名称调用参数：

def square(a: =>Int) = a * a

但这在它仅计算值的意义上并不是惰性的需要时一次：

scala> square({println("calculating");5})
calculating
calculating
res0: Int = 25

添加惰性方法参数方面已经做了一些工作，但尚未集成（下面的声明应打印“计算”上面只有一次）：

def square(lazy a: Int) = a * a

这是缺少的一块，尽管您可以使用本地惰性 val 来模拟它：

def square(ap: =>Int) = {
  lazy val a = ap
  a * a
}

关于可变性 - 没有什么可以阻止您编写不可变的数据结构并避免突变。您也可以在 Java 或 C 中执行此操作。事实上，一些不可变的数据结构依赖惰性原语来实现更好的复杂性界限，但是惰性原语也可以用其他语言进行模拟 - 以额外的语法和样板为代价。

您始终可以在 Scala 中编写不可变数据结构、惰性计算和完全纯的程序。问题是 Scala 编程模型也允许编写非纯程序，因此类型检查器不能总是推断出程序的某些属性（例如纯度），而考虑到编程模型的限制性更强，它可以推断出这些属性。

例如，在纯表达式语言中，上面的按名称调用定义中的 a * a (a: =>Int) 可以优化为计算 < code>a 仅一次，无论按名称调用语义如何。如果语言允许副作用，那么这种优化并不总是适用。

Regarding lazyness - currently, passing a parameter to a method is by default strict:

def square(a: Int) = a * a

but you use call-by-name parameters:

def square(a: =>Int) = a * a

but this is not lazy in the sense that it computes the value only once when needed:

scala> square({println("calculating");5})
calculating
calculating
res0: Int = 25

There's been some work into adding lazy method parameters, but it hasn't been integrated yet (the below declaration should print "calculating" from above only once):

def square(lazy a: Int) = a * a

This is one piece that is missing, although you could simulate it with a local lazy val:

def square(ap: =>Int) = {
  lazy val a = ap
  a * a
}

Regarding mutability - there is nothing holding you back from writing immutable data structures and avoid mutation. You can do this in Java or C as well. In fact, some immutable data structures rely on the lazy primitive to achieve better complexity bounds, but the lazy primitive can be simulated in other languages as well - at the cost of extra syntax and boilerplate.

You can always write immutable data structures, lazy computations and fully pure programs in Scala. The problem is that the Scala programming model allows writing non pure programs as well, so the type checker can't always infer some properties of the program (such as purity) which it could infer given that the programming model was more restrictive.

For example, in a language with pure expressions the a * a in the call-by-name definition above (a: =>Int) could be optimized to evaluate a only once, regardless of the call-by-name semantics. If the language allows side-effects, then such an optimization is not always applicable.

回复收藏 0 原文