声明性语言的实现细节本质上是命令式的吗
我正在阅读 Tomas Petricek & 的《函数式编程》。乔恩·斯基特和我了解声明式和声明式之间的区别。命令式编程。
我想知道原始运算符 & 是如何的？实现的函数是由命令式运算符和运算符构建的声明性语言。功能。
干杯
AWC
I'm reading 'Functional Programming' by Tomas Petricek & Jon Skeet and I understand the difference between declarative & imperative programming.
What I was wondering is how are the primitive operators & functions implemented, are declarative languages constructed from imperative operators & functions.
Cheers
AWC
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果我正确理解你的问题，我不认为这是一个硬性规定。例如，您可以使用像 Lisp 这样的函数式语言来为自己创建一个解释器。在这种情况下，实现细节是以函数式方式实现的（因为Lisp是函数式语言）。
此外，如果您有一种图灵完备的语言，您可以使用它来实现任何其他语言的解析器/解释器/编译器。有命令式图灵完备语言和函数式/声明式图灵完备语言。
但所有代码最终都会完成汇编或机器代码，这本质上是命令式的。从理论上讲，我上面说的是真的，但在实践中显然不是:)。
作为一个有趣的历史旁白，LISP 完全是一个理论构建。它是计算机语言的数学符号。在 Steve Russel 在 IBM 704 上用机器代码实现 LISP 的
eval函数之前，它一直停留在理论上：画家，p。 185、麦卡锡说：“史蒂夫·拉塞尔说，看，我为什么不编写这个评估......，我对他说，嗬，嗬，你混淆了理论与实践，这eval 是为了阅读，而不是为了计算，但他还是这么做了，那就是，他将我论文中的 eval 编译成 IBM 704 机器代码，修复了 bug，然后将其作为一个广告来宣传。 Lisp 解释器，确实如此。所以在那时 Lisp 基本上具有了今天的形式......”（强调我的）
因此，理论与实践之间的微妙之处再次出现。 :)
If I understand your question correctly, I don't think that is a hard and fast rule. For example, you can use a functional language like Lisp, to create an interpreter for itself. In this case, the implementation details are implemented in a functional manner (because Lisp is a functional language).
Also, if you have a language that is Turing Complete, you can use it to implement a parser/interpreter/compiler for any other language. There are imperative Turing-Complete languages, and functional/declarative Turing-Complete languages.
But all code eventually comes done to assembly or machine code, which is inherently imperative. In theory, what I said above is true, but apparently not in practice :).
As an interesting historical aside, LISP was a completely theoretical construct; it was a mathematical notation for computer languages. It remained theoretical until LISP's
evalfunction was implemented in machine code by Steve Russel on an IBM 704:According to what reported by Paul Graham in Hackers & Painters, p. 185, McCarthy said: "Steve Russell said, look, why don't I program this eval..., and I said to him, ho, ho, you're confusing theory with practice, this eval is intended for reading, not for computing. But he went ahead and did it. That is, he compiled the eval in my paper into IBM 704 machine code, fixing bug , and then advertised this as a Lisp interpreter, which it certainly was. So at that point Lisp had essentially the form that it has today..." (emphasis mine)
So once again, the subtleties between theory and practice. :)
低级机器（CPU、汇编语言级别）是必要的，因此显然在某些时候实现必须考虑到这一点。但是， 实现某些类型的函数式语言，例如Haskell 采用了一些非常不明显的方法来创建具有良好性能的运行时。
奇怪的是，大多数命令式语言都会经历一个阶段，所有代码都被转换为更具声明性：
下面是将Scheme（函数式）直接编译为C 代码（命令式）的示例：
The low level machine (CPU, assembly language level) is imperative so obviously at some point the implementation will have to take that into account. However, Implementing certain kinds of functional languages like Haskell takes some very non-obvious approaches to create a run-time with decent performance.
Strangely enough, most imperative languages go through a phase where all the code is transformed to be more declarative:
Here is an example of compiling Scheme (functional) directly to C code (imperative):
你的问题有点不清楚。在幕后，处理器指令本质上是命令式的。如果您的代码应该在冯诺依曼机器上运行，那么它最终应该作为命令式代码运行。
构建一台本质上支持这些操作的机器（具有某些特定的架构）是可能的。事实上，LispM 被设计来帮助运行 Lisp 程序。虽然我不熟悉 LispM 的硬件特性，但它可能确实有资格在更具声明性的级别上提供一些原始操作。
Your question is a bit unclear. Under the hood, processor instructions are imperative in nature. If your code is supposed to run on a von Neumann machine, it should be eventually run as imperative code.
It may be possible to build a machine (with some specific architecture) that inherently supports those operations. In fact LispM had been designed to help run Lisp programs. While I'm not familiar with the hardware characteristics of LispM, it probably does qualify as providing some primitive operations at a more declarative level.
有时。它是实现的属性，而不是语言的属性。
在 20 世纪 80 年代，很多人将函数式程序编译成图表，然后将图表重写为更简单的图表。此计算通常涉及就地更新图表，但除此之外，它就像您希望的那样是声明性的。要了解更多信息，请查找“图形简化”或阅读 Chris Clack 和 Simon Peyton Jones 撰写的“四冲程简化发动机”。
最终，编译器编写者找到了通过将函数程序直接编译为本机机器代码来获得更好性能的方法。如果本机机器是典型的商品机器，则这意味着典型的命令式操作。然而，如果你查阅麻省理工学院 Arvind 教授的开创性工作，他的团队设计并构建了数据流机器，其中基本计算操作本质上更具声明性。这是一项伟大的工作，但所有在 20 世纪 80 年代蓬勃发展的专用架构都已被伟大的 Microsoft/Intel 良性循环所淘汰（更多软件 -> 售出更多 PC -> 更便宜的处理器 -> 售出更多 PC - > ... -> 300 美元的上网本，功能非常酷）。
Sometimes. It is a property of the implementation, not the language.
In the 1980s, lots of people compiled functional programs to graphs, then rewrote the graphs to simpler graphs. This computation usually involved updating the graphs in place, but otherwise it was about as a declarative as you would like. To learn more, look up "graph reduction" or read "The four-stroke reduction engine" by Chris Clack and Simon Peyton Jones.
Eventually compiler writers figured out ways to get better performance by compiling functional programs directly to native machine code. If the native machine is a typical commodity machine, this means typical imperative operations. However, if you look up the pioneering work of Professor Arvind at MIT, his group designed and built dataflow machines where the fundamental computational operations are more declarative in nature. It was great work, but all the special-purpose architectures that flourished in the 1980s have been made extinct by the great Microsoft/Intel virtuous cycle (more software -> more PCs sold -> cheaper processors -> more PCs sold -> ... -> $300 netbooks that do really cool stuff).
实施是隐藏在幕后的。它可以用任何范例来构建。
声明式程序只是其一些或多或少的“通用”命令式实现/vm 的数据。
优点：
仅以某种硬编码（和检查）格式指定数据比直接指定某些命令式算法的变体更简单且不易出错。一些复杂的规范无法直接编写，只能以某种 DSL 形式编写。
DSL 数据结构中使用的最佳和频率是集合和表格。因为元素/行之间没有依赖关系。当您没有依赖项时，您可以自由修改并轻松获得支持。 （例如，将模块与类进行比较 - 与您满意的模块相比，与您遇到脆弱基类问题的类）
声明性和 DSL 的所有好处都立即受益于该数据结构（表和集）的好处。
另一个优点 - 如果 DSL 或多或少是抽象的（设计良好），您可以更改声明性语言 vm 的实现。例如，进行并行实施。或将其移植到其他操作系统等。所有良好的指定模块化隔离接口或协议都为您提供了如此自由和轻松的支持。
缺点：
你猜对了。通用（并由 DSL 参数化）命令式算法/vm 实现可能比特定算法/vm 更慢和/或占用内存更大。在某些情况下。
如果这种情况很少见，那就忘记它吧，慢慢来。如果它很频繁 - 您始终可以针对这种情况扩展您的 DSL/vm。当然，在某些地方会减慢所有其他情况...
PS 框架介于 DSL 和命令式之间。作为所有半途而废的解决方案......它们结合了缺陷，而不是好处。它们不是那么安全，也不是那么快:) 看看万事通的 haskell - 它介于强大的简单 ML 和灵活的 metaprog Prolog 之间，而且......它是一个多么可怕的怪物。你可以将 Prolog 视为具有纯布尔函数/谓词的 Haskell。与 Haskell 相比，它的灵活性是多么简单......
implementation is that' hidden under the hood. it can be builded with any paradigm.
declarative program is just a data for its some more-or-less "universal" imperative implementation/vm.
pluses:
specifying just a data, in some hardcoded (and checked) format, is simpler and less error-prone than specifying variant of some imperative algorithm directly. some complex specifications just cant be written directly, only in some DSL form.
best and freq used in DSLs data structures is sets and tables. because you not have dependencies between elements/rows. and when you havent dependencies you have freedom to modify and ease of support. (compare for example modules with classes - with modules you happy and with classes you have fragile base class problem)
all goods of declarativeness and DSL follows immediately from benefits of that data structures (tables and sets).
another plus - you can change implementation of declarative language vm, if DSL is more-or-less abstract (well designed). make parallel implementation, for example. or port it to other os etc. all good specifed modular isolating interfaces or protocols gives you such freedom and easyness of support.
minuses:
you guess right. generic (and parameterized by DSL) imperative algorithm/vm implementation may be slower and/or memory hungry than specific one. in some cases.
if that cases is rare - just forget about it, let it be slow. if it's frequient - you always can extend your DSL/vm for that case. somewhere slowing down all other cases, sure...
P.S. Frameworks is half-way between DSL and imperative. and as all halfway solutions ... they combines deficiences, not benefits. they not so safe AND not so fast :) look at jack-of-all-trades haskell - it's halfway between strong simple ML and flexible metaprog Prolog and... what a monster it is. you can look at Prolog as a Haskell with boolean-only functions/predicates. and how simple its flexibility is against Haskell...