sicp 4.2.2小节部分习题
2023-03-14 10:25:29 时间
4.27,
至于原因,w在没有强迫求值前,仅仅执行了一步(id 10),因此此时count为1,当要求打印w的时候force执行了第二步(id 10),因此count增加为2。
4.28,当参数也是函数的时候,例如:
如果对operator不采用actual-value,那么square将延时求值,在执行(proc a)时无法辨认eval的过程类型。
4.29,俺第一个想到的就是树形递归的斐波那契数列:
第二问,有趣的地方在于square过程,注意到(define (square x) (* x x)),x在body出现了两次,那么如果是使用不带记忆功能的force-it, x将被求值两次,如果x本身带有副作用(例如例子里面的id过程),那么显然副作用也将被调用两次,因此答案不言自明。带记忆功能的force-it版本中,count将仍然是1,而在不带记忆功能的版本中count将增长到2。
4.30,第一问,我也谈不出所以然为什么ben的说法是正确的,关注下第二问的两个过程在不同eval-sequence下的表现,(p1 1)的结果没有改变都是(1 2),而(p2 1)在原始版本的eval-sequence中结果是1,而在Cy修改后的版本中(对中间步骤采用actual-value)结果是(1 2),也就是说在原始版本中的(set! x (cons x '(2)))的副作用根本没有实现,而在修改后的版本中实现了。俺觉的这个问题很迷惑,惰性求值与side effect相互作用很奇特,不过我更偏向原始版本,因为我觉的这样的实现更容易看清代码的意图,也就是说在透明性上更好,例如我分析p2过程就可以认为直接返回参数x;而实现副作用很容易让人掉入陷阱,并且很可能引进难以查找的bug。
文章转自庄周梦蝶 ,原文发布时间2008-11-02
;;; L-Eval input:
(define count 0)
;;; L-Eval value:
ok
;;; L-Eval input:
(define (id x)
(set! count (+ 1 count))
x)
;;; L-Eval value:
ok
;;; L-Eval input:
(define w (id (id 10)))
;;; L-Eval value:
ok
;;; L-Eval input:
count
;;; L-Eval value:
1
;;; L-Eval input:
w
;;; L-Eval value:
10
;;; L-Eval input:
count
;;; L-Eval value:
2
(define count 0)
;;; L-Eval value:
ok
;;; L-Eval input:
(define (id x)
(set! count (+ 1 count))
x)
;;; L-Eval value:
ok
;;; L-Eval input:
(define w (id (id 10)))
;;; L-Eval value:
ok
;;; L-Eval input:
count
;;; L-Eval value:
1
;;; L-Eval input:
w
;;; L-Eval value:
10
;;; L-Eval input:
count
;;; L-Eval value:
2
至于原因,w在没有强迫求值前,仅仅执行了一步(id 10),因此此时count为1,当要求打印w的时候force执行了第二步(id 10),因此count增加为2。
4.28,当参数也是函数的时候,例如:
(define square (lambda(x) (* x x)))
(define (test proc a)
(proc a))
(test square 3)
(define (test proc a)
(proc a))
(test square 3)
如果对operator不采用actual-value,那么square将延时求值,在执行(proc a)时无法辨认eval的过程类型。
4.29,俺第一个想到的就是树形递归的斐波那契数列:
(define (fib n)
(cond ((= 0 n) 0)
((= 1 n) 1)
(else
(+ (fib (- n 1)) (fib (- n 2))))))
不带记忆功能和带记忆功能的force-it之间的性能差距非常明显。(cond ((= 0 n) 0)
((= 1 n) 1)
(else
(+ (fib (- n 1)) (fib (- n 2))))))
第二问,有趣的地方在于square过程,注意到(define (square x) (* x x)),x在body出现了两次,那么如果是使用不带记忆功能的force-it, x将被求值两次,如果x本身带有副作用(例如例子里面的id过程),那么显然副作用也将被调用两次,因此答案不言自明。带记忆功能的force-it版本中,count将仍然是1,而在不带记忆功能的版本中count将增长到2。
4.30,第一问,我也谈不出所以然为什么ben的说法是正确的,关注下第二问的两个过程在不同eval-sequence下的表现,(p1 1)的结果没有改变都是(1 2),而(p2 1)在原始版本的eval-sequence中结果是1,而在Cy修改后的版本中(对中间步骤采用actual-value)结果是(1 2),也就是说在原始版本中的(set! x (cons x '(2)))的副作用根本没有实现,而在修改后的版本中实现了。俺觉的这个问题很迷惑,惰性求值与side effect相互作用很奇特,不过我更偏向原始版本,因为我觉的这样的实现更容易看清代码的意图,也就是说在透明性上更好,例如我分析p2过程就可以认为直接返回参数x;而实现副作用很容易让人掉入陷阱,并且很可能引进难以查找的bug。
文章转自庄周梦蝶 ,原文发布时间2008-11-02
相关文章
- 在 Go 里用 CGO?这 7 个问题你要关注!
- 9款优秀的去中心化通讯软件 Matrix 的客户端
- 求职数据分析,项目经验该怎么写
- 在OKR中,我看到了数据驱动业务的未来
- 火山引擎云原生大数据在金融行业的实践
- OpenHarmony富设备移植指南(二)—从postmarketOS获取移植资源
- 《数据成熟度指数》报告:64%的企业领袖认为大多数员工“不懂数据”
- OpenHarmony 小型系统兼容性测试指南
- 肯睿中国(Cloudera):2023年企业数字战略三大趋势预测
- 适用于 Linux 的十大命令行游戏
- GNOME 截图工具的新旧截图方式
- System76 即将推出的 COSMIC 桌面正在酝酿大变化
- 2GB 内存 8GB 存储即可流畅运行,Windows 11 极致精简版系统 Tiny11 发布
- 迎接 ecode:一个即将推出的具有全新图形用户界面框架的现代、轻量级代码编辑器
- loongarch架构介绍(三)—地址翻译
- Go 语言怎么解决编译器错误“err is shadowed during return”?
- 敏捷:可能被开发人员遗忘的部分
- Denodo预测2023年数据管理和分析的未来
- 利用数据推动可持续发展
- 在 Vue3 中实现 React 原生 Hooks(useState、useEffect),深入理解 React Hooks 的