问题标签 [callcc]

我正在编写一个需要递归分析“命令”和“程序”列表的程序（它是我们的教授为生活在迷宫中的机器人发明的某种“机器人语言”的解释器）。因为我最初的实现太慢了，所以我决定使用 call-with-current-continuation。

我知道 call/cc 是如何工作的，我已经阅读了这个和这个作为解释。

我的电话/抄送是基于这部分教程：

通常我们想使用 call-with-current-continuation 来调用一些带有参数而不是转义过程的过程。例如，我们可能有一个过程，除了转义过程之外还有两个参数，因此：

(define (foo xy escape) ... (if (= x 0) (escape 'ERROR)) ...)) 我们可以通过对过程进行柯里化来解决这个问题，使其成为一个参数的过程。

[ 前面的章节应该讨论柯里化！]

假设我们想要传递 0 和 1 作为 x 和 y 的值，并将转义过程交给 foo。而不是说

(call-with-current-continuation foo) 没有将足够的参数传递给对 foo 的调用，我们说

(call-with-current-continuation (lambda (escape) (foo 0 1 escape))) lambda 表达式创建了一个完全符合我们要求的闭包。它将使用参数 0、1 和由 call-with-current-continuation 创建的转义过程调用 foo。

但是，由于某种原因它不起作用并引发此异常：

我希望你能帮我找出我的错误并解释它发生的原因......

这是与此问题相关的代码部分：

Scheme 提供了一个原语call-with-current-continuation，通常缩写为call/cc，它在 ANSI Common Lisp 规范中没有等价物（尽管有一些库试图实现它们）。

有人知道为什么决定不在 ANSI Common Lisp 规范中创建类似的原语吗？

据我所知，Ruby 是唯一同时支持call/cc和try/catch/finally（写成begin/rescue/ensure/end块）的主流语言。

我不熟悉 Ruby，但我的直觉告诉我这两者可能存在冲突，因为call/cc允许任意控制流并ensure需要一些有保证的控制流（某些代码路径必须在预定义的情况下执行，即离开包含堵塞）。

那么，语言中是否存在任何冲突？如果是这样，在这种情况下，语言的定义行为是什么？特别是，如果call/cc在begin/ensure块或块中使用会发生什么ensure/end？如果call/cc在块包含ensure子句之后调用捕获怎么办？

Continuation describes what happens next with some value, right? Isn't that just a function that takes a value and does some computation?

the continuation of (* 2 3) is (+ _ 5)

What is the point of using call/cc in here and not using the function k ?

在 Scheme 中，执行从 a 获得的延续call/cc会有效地跳回到初始调用/cc 并恢复保存的调用堆栈。

我刚开始学习 Haskell，我正试图弄清楚如何理解callCC. 那就是尝试callCC从对Scheme的理解方面来理解call/cc。的实现callCC是

据我所知，没有提到与保存或恢复调用堆栈有关的内容。callCC来自对 Scheme 的熟悉如何解释Haskell 中的call/cc.

编辑：也许如果有人可以将以下内容翻译成 Haskell，这将有助于我理解。

我无法理解上一个问题的答案。我希望对以下内容的解释能够澄清事情。以下示例来自fpcomplete

输出是

我想我理解这个例子是如何工作的，但是为什么有必要let在“返回”延续中使用一个表达式，callCC以便以后可以使用它。所以我尝试通过以下更简单的示例并对其进行修改来直接返回延续。

这打印

我将其修改为以下

f这个想法是在我希望打印的这个测试示例中，延续将被返回并且未被使用

但是这个例子不能编译，为什么不能这样做呢？

编辑：考虑Scheme中的类似例子。据我所知，Scheme 不会有问题，对吗？但是为什么呢？

考虑下面的 Haskell 函数示例quux以及延续 monad 和 的定义callCC。

据我了解这个例子。do 块可以被认为是

我们可以从它的定义中k看出\a -> cont $ \_ -> h a，在上面我们已经\x -> runCont ((\_ -> return 25) x) c被传入了被下划线忽略的参数。最终，它return 25被有效地“忽略”了，因为从未使用下划线参数，因此从惰性评估中它从未被评估过。

据我所知，这种实现从callCC根本上依赖于惰性求值。这callCC将如何在严格（非惰性）函数式语言中完成？

在 Clojure 的core.async 库中，我们看到一个宏，它创建一个状态机，该状态机环绕go块以创建处理阻塞 IO 的通道。

这似乎是在C#和Go-lang 的 goroutines上建模 。async

在 The Seasoned Schemer中，他们描述了传递延续的技术。（这似乎基于 call/cc）。我们还看到了来自David Nolen的关于Clojure中分隔延续的库。

在这里，他们将 C# 描述async为 ' call with current continuation '。

我的问题是我们可以将 Clojure 的 core.async 描述为“延续传递风格”吗？

还是“延续”（定界和未定界）是一个超载的术语？

编辑：另外说明 - David Nolen对 core.async 说过：

在 go 块内部，它给您一种错觉，即您可以以同步的方式执行这些操作，因此您不必手动以连续传递样式编写代码。

在过去的几天里，我一直在玩方案（特别是诡计）的延续，对某些函数的结果有点困惑，想知道是否有人能准确地解释这里发生了什么。

有一个调用的函数(get-token)将检索给定文件中的下一个找到的令牌。例如，如果接下来的 3 个标记是“a”、“b”和“c”，调用 (get-token) 将在第一次调用时返回“a”，在第二次调用时返回“b”，和“c”第三次被调用。

我想做的是有一个函数(peek-token)，它将调用(get-token)，返回令牌，然后返回到(get-token)调用函数之前的状态。我尝试了多种不同的方法来实现这一结果，我目前拥有的方法是：

我现在如何理解它，bind/cc将首先保存一个延续，return然后执行以下代码块。然后当return再次被击中时，程序跳回到继续绑定的地方，并token给出值作为结果。

但是，当我运行上述函数时，结果与原始函数完全相同(get-token)。

如果有人能解释我哪里出错了，或者表达一种更好的方法来获得相同的结果，我将非常感激（我知道有些人讨厌走电话/抄送的方式）。

读完《老谋深算》后，我觉得我理解call/cc正确。但是，在看到一些 WOW 技巧后，call/cc我发现我错了。

这完全符合我的理解。我想当我call/cc接到电话时，我只是在保存程序状态。并用函数调用它旁边的函数。如果从某个地方调用该函数 ( )，那么我只是用给它的参数k替换整个东西。上面的程序似乎也是这样工作的(call/cc ...)

但，

调用next3 次会产生 0、1 和'done. 这意味着当state使用它提供的功能时k，generator它并没有恢复程序的状态。我只是向你展示了我试图理解它。

那么，call/cc实际上是如何工作的呢？