如何解决程序什么时候“交织定义和使用”？
嵌入式定义必须首先出现在过程主体中。管理层对运行将定义和使用交织在一起的程序的后果不承担任何责任。
这到底是什么意思？我了解：
- “ 定义”指的是过程创建和值分配。
- “ 过程主体”为as defined in section 1.1.4。这是过程定义中的参数列表之后的代码。
- “ 嵌入的定义必须首先出现在过程主体中”表示“ 在过程的主体中创建和使用的任何定义都必须先于其他事物”。 / li>
- “ 交错定义并使用”表示“ 在定义过程之前调用过程或赋值;”
但是，这种理解似乎与this question的答案相矛盾，我的答案可以概括为“ ”，您引用的错误是关于在程序主体开始时使用定义的错误。 依赖于同样在该机构开头的定义 ”。这让我一头雾水：
- 这种解释显然与我上面所说的相矛盾，但是似乎有很强的证据-编译器规则-其背后。
- SICP似乎很高兴将定义与使用它们的其他定义放在一起。只需看看
sqrt过程just above the footnote！ - 乍一看，在我看来，链接问题的作者的真实错误是将
num-prod视为num定义中的值，而不是将其视为过程。但是，作者显然使它起作用了，所以我可能是错的。
那到底是怎么回事？误会在哪里？
解决方法
在给定过程的定义/代码中，
- “内部定义” 是以
define开头的表格。 - “过程主体” 是所有以
define开头的形式之后的其他形式。 - “嵌入式定义必须首先出现在过程主体中” 表示所有内部
define形式都必须首先走，然后再处理所有其他内部形式。一旦出现非define内部表单，此后就不会再出现内部define表单。 - “不交织使用” 表示在定义之前不使用任何名称。想象一下，所有内部
define表单都收集到一个等效的letrec中，并遵循其规则。
也就是说，我们有
(define (proc args ...)
;; internal,or "embedded",definitions
(define a1 ...init1...)
(define a2 ...init2...)
......
(define an ...initn...)
;; procedure body
exp1 exp2 .... )
任何ai都可以在任何initj表达式中使用，但只能在lambda表达式中使用。（*）否则它将引用{{ 1}}在定义ai时，这是禁止的，因为在评估任何aj表达式时都认为尚未定义任何ai名称。
（*）请记住，initj与(define (foo x) ...x...)相同。这就是为什么您提到的书中的(define foo (lambda (x) ...x...))过程中的定义都可以的原因-它们都是sqrt表达式，并且在lambda表达式中使用的任何名称实际上仅在lambda表达式中引用该名称的值。表达式的值-一个lambda函数-将被调用，而不是在评估该lambda表达式时调用该函数，从而生成作为其值的lambda函数。
这本书起初对其语言的确切语义有点含糊，但是in Scheme上面的代码等效于
lambda例如，
(define proc
(lambda (args ...)
;; internal,definitions
(letrec ( (a1 ...init1...)
(a2 ...init2...)
......
(an ...initn...) )
;; procedure body
exp1 exp2 ....
)))
首先计算lambda表达式 ;; or,equivalently,(define (my-proc x) (define my-proc
(lambda (x)
(define (foo) a) (letrec ( (foo (lambda () a))
(define a x) (a x) )
;; my-proc's body ;; letrec's body
(foo)) (foo))))
，并将名称(lambda () a)绑定到结果函数中；该函数将引用foo的值当将调用a 时，因此可以引用(foo)在该lambda表达式内-因为当评估该lambda表达式时，无需立即使用a的值，而只需引用其{em> future 值，其名称为a，在那里也就是说，a 将在 all 之后具有的值被初始化，其中a中的名称被初始化，并且输入letrec的主体。换句话说，当所有内部letrec完成并输入过程define的正文时。
因此，我们看到已定义my-proc，但在初始化期间未使用它； foo已定义，但在初始化期间未使用；因此一切都很好。但是如果我们有
a然后在此(define (my-proc x)
(define (foo) x) ; `foo` is defined as a function
(define a (foo)) ; `foo` is used by being called as a function
a)
既是在内部foo或“嵌入式” define初始化期间定义的和；计划中禁止这样做。这就是本书所警告的：内部定义只允许定义内容，但是当我们完成内部define并输入整个过程的主体时，应延迟使用内部定义。 / p>
这很微妙，正如脚注和您所引用的问题所暗示的那样，具体内容可能会因特定语言的实现而异。
这些问题将在本书的后面部分（第3章和第4章）中进行详细介绍，并且通常情况下，本文避免使用内部定义，以便可以避免这些问题，直到对其进行详细研究为止。
脚注上方的代码之间的主要区别：
(define (sqrt x)
(define (good-enough? guess)
(< (abs (- (square guess) x)) 0.001))
(define (improve guess)
(average guess (/ x guess)))
(define (sqrt-iter guess)
(if (good-enough? guess)
guess
(sqrt-iter (improve guess))))
(sqrt-iter 1.0))
和另一个问题中的代码：
(define (pi-approx n)
(define (square x) (* x x))
(define (num-prod ind) (* (* 2 ind) (* 2 (+ ind 1)))) ; calculates the product in the numerator for a certain term
(define (denom-prod ind) (square (+ (* ind 2 ) 1))) ;Denominator product at index ind
(define num (product num-prod 1 inc n))
(define denom (product denom-prod 1 inc n))
是前者中的所有定义都是过程定义，而num和denom是 value 定义。在调用该过程之前，不会对过程的主体进行评估。但是，在分配值时会评估值定义。
使用值定义：
(define sum (add 2 2))
(add 2 2)，如果已经定义了add。但是具有过程定义：
(define (sum n m) (add n m))
过程对象将分配给sum，但是过程主体尚未评估，因此在定义add时不需要定义sum，但必须在{ {1}}被称为：
sum正如我所说的，有很多细微之处和很多变化，所以我不确定对于方案的每个而言，以下内容是否总是 正确，你可以说“ SICP方案”。
有效（对(sum 2 2)
的评估顺序不重要）：
define也有效：
;procedure body
(define (sum m n) (add m n))
(define (add m n) (+ m n))
(sum 2 2)
通常无效（对;procedure body
(define (sum) (add 2 2))
(define (add m n) (+ m n))
(sum)
s的评估顺序很重要）：
define以下内容是否有效取决于实现方式：
;procedure body
(define sum (add 2 2))
(define (add m n) (+ m n))
最后是相互定义和使用的示例，是否奏效还取决于实现。 IIRC，如果已实现 scanning out ，则可以与本书第4章中所述的Scheme一起使用。
;procedure body
(define (add m n) (+ m n))
(define sum (add 2 2))
这是复杂而微妙的，但关键点是：
- 值定义与过程定义的评估方式不同，
- 内部区块的行为可能与外部区块不同，
- 方案实现之间存在差异，
- 这本书的设计目的是让您不必担心这一点，直到第三章为止。
- 这本书将在第4章中详细介绍。
您发现了计划的困难之一。和口齿不清。由于出现这种chicken and egg问题，因此没有单一的口齿不清，但出现了许多口齿不清。
如果绑定形式在R5RS的letrec-逻辑和R6RS的letrec*-逻辑中不存在，则语义为未定义。这意味着，一切都取决于方案实施者的意愿。
请参阅论文修复Letrec：方案的递归绑定构造的可靠而有效的实现。
此外，当不同方案的实施者之间没有达成普遍共识时，您可以阅读mailing list from 1986中的讨论。
此外，麻省理工学院开发了两种版本的方案-学生版和研究人员的开发版，它们在define形式的顺序上有不同的表现。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。