"Scheme 是为了研究 Actor 模型是发明的"

[tiye]

最开始是微博上有人指点说 Scheme 是为了 Actor 发明出来的

另外 Scheme 应该是为了研究 Actor 并发模型而发明出来的，不是为了研究面向对象。 详见 Scheme An interpreter for extended lambda calculus - Sussman, Steele - 1975

另外推荐的关于编程语言历史视频我目前还没闲下来看

下午遇到一份 History of the Actor model, 有一段关于 Scheme:

Gerald Sussman and Guy Steele then took an interest in Actors and published a paper on their Scheme interpreter in which they (misleadingly) concluded "we discovered that the 'actors' and the lambda expressions were identical in implementation." The actual situation is that the lambda calculus is capable of expressing some kinds of parallelism but, in general, not the concurrency expressed in the Actor model. On the other hand, the Actor model is capable of expressing all of the parallelism in the lambda calculus.

大意 Scheme 模拟的是广泛的并行, 而不是 Actor 中定义的并行 另外上边提到的两人是 Scheme 的作者, 在 Scheme 的 Wiki 中写了 Wiki 还写了, Scheme 是为研究 Actor 而发明的, 而静态词法域正是从 Actor

Scheme started as an attempt to understand Carl Hewitt's Actor model, for which purpose Steele and Sussman wrote a "tiny Lisp interpreter" using Maclisp and then "added mechanisms for creating actors and sending messages."

另外在 Actor 模型的作者的 Wiki 里也提到了关于 Scheme:

Sussman and Steele developed the Scheme programming language in an effort to gain a better understanding of the Actor model. However, their Scheme interpreter was not capable of fully implementing the Actor model because Actor customers cannot be implemented as lambda calculus continuations and Actors can change their local state in a way that is impossible in the lambda calculus [4][39] A number of programming languages were developed to specifically implement the Actor model, such as ACT-1,[40] SALSA,[41] Caltrop,[42] E[8] and ActorScript.[13] The Actor model also influenced the development of the π-calculus.[43](See Actor model and process calculi history.)

好像是说 Scheme 无法模拟 Actor 模型中 Actor 内部状态的改变无法在 S 表达式表示出来 这么说 Scheme 又应该是不能模拟 Actor 了.. 概念多了真是糊涂了...

我中间想, HTTP 每个服务端客户端, 那么多的, 应该算是 Actor 模型的实现的吧 另外这么多年概念变来变去就像是有些人明明很有名, 可在几百年前已经死去了 搅成一堆, 的确更应该把当下的技术先学好, 不然更糊涂了

[Liutos]

最后的一个引用，说的

is impossible in the lambda calculus

说的是lambda calculus吧，Scheme不仅仅是lambda calculus，它有set!可以改变词法作用域变量的值，作者的意思应该是在单纯的lambda演算中无法实现而已吧，毕竟lambda calculus只有两条规则，没有赋值。

[tiye]

忘了去看 Scheme Wiki 上的内容, 手动帖一遍过来

In 1971 Sussman, Drew McDermott, and Eugene Charniak had developed a system called Micro-Planner which was a partial and somewhat unsatisfactory implementation of Planner. Sussman and Hewitt worked together along with others on Muddle (later MDL), an extended Lisp which formed a component of Hewitt's ambitious Planner project. Drew McDermott, and Sussman in 1972 developed the Lisp-based language Conniver, which revised the use of automatic backtracking in Planner which they thought was unproductive. Hewitt was dubious that the "hairy control structure" in Conniver was a solution to the problems with Planner. Pat Hayes remarked: "Their [Sussman and McDermott] solution, to give the user access to the implementation primitives of Planner, is however, something of a retrograde step (what are Conniver's semantics?)"[8]

In November 1972, Hewitt and his students invented the Actor model of computation as a solution to the problems with Planner.[9] A partial implementation of Actors was developed called Planner-73 (later called PLASMA). Steele, then a graduate student at MIT, had been following these developments, and he and Sussman decided to implement a version of the Actor model in their own "tiny Lisp" developed on top of MacLisp, in order to understand the model better. Using this basis they then began to develop mechanisms for creating actors and sending messages.[10]

PLASMA's use of lexical scope was similar to the lambda calculus. Sussman and Steele decided to try to model Actors in the lambda calculus. They called their modeling system Schemer, eventually changing it to Scheme to fit the six-character limit on the ITS file system on their DEC PDP-10. They soon concluded Actors were essentially closures that never return but instead invoke a continuation, and thus they decided that the closure and the Actor were, for the purposes of their investigation, essentially identical concepts. They eliminated what they regarded as redundant code and, at that point, discovered that they had written a very small and capable dialect of Lisp. Hewitt remained critical of the "hairy control structure" in Scheme[11] and considered primitives (e.g., START!PROCESS, STOP!PROCESS and EVALUATE!UNINTERRUPTIBLY) used in the Scheme implementation to be a backward step.

25 years later, in 1998, Sussman and Steele reflected that the minimalism of Scheme was not a conscious design goal, but rather the unintended outcome of the design process. "We were actually trying to build something complicated and discovered, serendipitously, that we had accidentally designed something that met all our goals but was much simpler than we had intended... we realized that the lambda calculus—a small, simple formalism—could serve as the core of a powerful and expressive programming language." [10]

On the other hand, Hewitt remained critical of the lambda calculus as a foundation for computation writing "The actual situation is that the λ-calculus is capable of expressing some kinds of sequential and parallel control structures but, in general, not the concurrency expressed in the Actor model. On the other hand, the Actor model is capable of expressing everything in the λ-calculus and more." He has also been critical of aspects of Scheme that derive from the lambda calculus such as reliance on continuation functions and the lack of exceptions

@Liutos 对照你的说法的话.. 我觉得你说 "Scheme 不仅仅是 lambda" 有道理 看最后一段话的语气, Actor 模型是超出了 lambda calculus. 而 Scheme 满足了他们的预期

[ypyf]

R5RS里面的描述：

严格尾递归是 Steele 和 Sussman 最初版本的 Scheme 中的核心概 念之一。第一个 Scheme 解释器既实现了函数，也实现了参与者 (Actor)。控制流用参与者来表示。参与者和函数的不同在于， 参与者将其结果传给另一个参与者，而非返回给调用者。用本节 的术语来说，每个参与者最终都通过尾调用访问另一个参与者。

Steele 和 Sussman 后来注意到，在他们的解释器里，处理参与者 的代码与处理函数的代码是一样的，完全没有必要在语言中同时 包含这两种特征。

[ypyf]

scheme里面没有actor的概念了

[tiye]

@ypyf Actor 的概念在语言当中是什么样子我不清楚, 讲解下么?

[ypyf]

@jiyinyiyong http://en.wikipedia.org/wiki/History_of_the_Actor_model

[FrankHB]

From arXiv:1008.1459v33 p36:

The λ-calculus includes the following limitations:

• Message reception order cannot be implemented.
• Actors that change cannot be implemented
• The λ-calculus does not have exceptions and consequently neither did Scheme [Sussman and Steele 1975].
• Attempting to reduce Actor customers to continuation functions was problematical, e.g., it led to the hanging customer issue (see above).
• Using the λ-calculus to simulate Actors systems is exponentially slower in many practical applications.

[tiye]

论文不熟, 早上看唐凤的演讲, 里边有个说法, Scheme 就是为了应对面向对象而研究出来的, 他说 Lambda 里只要加入一个功能就可以满足所有面相对象的功能了: "由外层函数提供里面的自由变数的 Closure 的闭包".. 虽然看不懂这话什么意思.. http://v.youku.com/v_show/id_193347568.html @FrankHB 不清楚和上边是否有关?

[ypyf]

@jiyinyiyong 估计就是说的π演算

[tiye]

@ypfy 演讲里没说清楚, 但是合起来看意思应该是这个意思没错.. 不敢看人论文, 现在这个囧啊.

[FrankHB]

Lambda Papers澄清了如何基于λ-calculus解决某些问题。 使用closure解决的主要问题是如何在对象里保存状态。而“如何实现面向对象”并没有特别明确地被作为一个外延明确的问题来解决。考虑到“面向对象”这个概念本身就比较含糊，不同作者可能会有不同解释，而之后以（面向对象里所谓的）对象作为基础的形式化（例如这个）也比较复杂且并没有被广泛接受（相对λ-calculus），所以这里没有重点强调是合理的。 其它相关问题参考维基条目。