为什么 lambda 演算没有被广泛使用(根本)?

发布于 2024-10-16 11:34:51 字数 72 浏览 1 评论 0原文

为什么纯无类型 lambda 演算经常被描述为无法使用?

有了合适的函数库,它会不会与任何其他函数式语言大致相同?

Why is pure untyped lambda calculus often described as being impossible to use?

With a suitable library of functions would it not be about the same as any other functional language?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

宫墨修音 2024-10-23 11:34:52

从理论上来说,理论和实践是一样的。但实际上,情况并非如此。

理论上它只是另一种函数式语言。但是您是否考虑过使用教堂数字进行数学计算对性能的影响?是的,你可以做到。但你的程序运行速度会非常慢,看起来会严重损坏。实用的函数式语言必须找到方法,在提供可构建的抽象和使用常用事物的快速、本机实现之间进行务实的权衡。

In theory, theory and practice are the same. In practice, they are not.

In theory it would be just another functional language. But have you considered the performance implications of actually doing math with Church numerals? Yes, you can do it. But your programs will run so slowly that they will look severely broken. A practical functional language must find ways to make a pragmatic tradeoff between providing abstractions that can be built upon, and using fast, native implementations of commonly used things.

风苍溪 2024-10-23 11:34:51

速度不是一个大问题。例如,您可以决定使用教堂数字,但优化实现,以便数字像平常一样表示——以对用户完全透明的方式。显然,结果数字在任何语言中的表现都会一样好——除非人们尝试实现自己的算术运算并发现它们不如实现中的快,或者当他们发现使用内置的 7 比相应的 lambda 表达式快得多...但这指出了一个更糟糕的问题。在普通 lambda 演算中,只有单参数函数。这意味着您正在使用非常低级的类似汇编的语言,其中没有类型错误,因为一切都只是函数。事实上,如果您坚持使用简单的 lambda 演算,则根本不会出现任何错误。机器代码的类比在这里非常相关:在那里,您也可以做任何您想做的事情——添加两个字符串,结果将是一些随机数。在 lambda 演算语言中,将一些列表编码发送到数字函数,它会很高兴地返回一个(虚假的)答案。

Speed is not a big issue. For example, you could decide to use church numerals but optimize the implementation so numbers are represented as usual -- in a way that is completely transparent to the user. The resulting numbers would obviously perform as well as in any language -- except when people try to implement their own arithmetical operations and discover that they're not fast as the one from the implementation, or when they discover that using a builtin 7 is much faster than the corresponding lambda expression... But that points at a much worse problem. In plain lambda calculus there are only one-argument functions. This means that you're working in a very low level assembly-like language where there are no type errors since everything is just functions. In fact, if you stick with just plain lambda calculus, there are no errors at all. The analogy to machine code is very relevant here: there, you can also do whatever you want -- add two strings, and the the result would be some random number. In a lambda calculus language, send some list encoding to a numeric function, and it will happily return a (bogus) answer.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文