1175_SICP学习笔记_map-列表元素的批量处理

    全部学习汇总： GitHub - GreyZhang/g_SICP: learn SICP and hack lisp.

    一个很有用的处理就是对列表元素的批量处理，比如，对元素进行一个因子的乘积。上面的代码设计师一个递归的设计，在理解设计上的确是一个很有效的设计方式。之前，我自己使用python的时候大部分的处理都是很基础的操作，使用这种批量处理模式的时候偏少。后面可以借鉴一下，这的确是可以让代码简化且更加容易理解维护。

    如果利用高阶抽象，可以把这个过程抽象出来一个map函数。这样，批量处理的形式更加自由了。其实，最初学习python的时候似乎是见过这样的设计，只是我用得python十分肤浅，可能旧代码的复用也就很容易实现我自己的需求。由此，倒是削弱了我对这方面的探索诉求。

    通过高阶抽象实现了map之后，重新设计的scale-list看起来是简洁清晰了很多。

    关于这个联系，第一个应该可以算作是即将被我淘汰的一种设计了。设计的模式其实考虑起来也简单，跟比例因子处理一样，一个递归就可以了。第二个实现，即使是没有square，加一个lambda也是很容易操作的。

(define (square-list l)

  (map (lambda (x) (* x x)) l))

    做一个简单的测试：

    运行的效果没有问题。后面的这种设计模式的确是一个更加容易扩展的模式，软件随着复杂度以及规模的增加会越来越显示出优势。在C语言设计中，类似的抽象其实也应该进行考虑。

    关于这个问题，理解起来还是很容易的。为什么顺序是反着的呢？这个顺序是不断使用cons在前面追加的一个过程，取数据的时候顺序是从前往后，但是cons的过程则是从里到外，也就是从后向前的一个过程。因此，计算出来的数据肯定是顺序相反的。

    这个设计，从处理数据的顺序角度思考的必要性其实就没有了。前面实现append等函数的时候其实做过分析，如果想要重新构建新的list从前面进行增补要比后面增补容易得多。因为，要保证最后一个原始是nil，这是一个必须要遵守的前提。

    这是for-each的说明，这个功能实现与map的差异在于不会修改原始的数据而是生成新的数据或者动作。

(define (for-each p-name l-name)

  (cond ((= 1 (length l-name))

         (p-name (car l-name)))

        (else

         (p-name (car l-name))

         (for-each p-name (cdr l-name)))))

    没有看过参考的答案，感觉上实现起来没有什么太大的难点。可能，设计的可能性会有很多，我也只是实现了其中的一种。目前，接触到的lisp技巧中，似乎很少见到顺序执行的结构，能够找到的只有一个cond。

    这是运行的结果，运行的效果还是可以的。

    关于map以及foreach的差异：map其实是一个数据的修改器，会对后面的数据进行修正调整。而for-each只是一个批处理的方式。这么看，严格意义上说，foreach其实是可以完成map的所有的功能的，某些场景之下map可能会更加简单一些。