拥有集合化特性的程序语言能让我们用很少的语句写出针对集合的复杂运算，其中处于核心地位的是 Lambda 语法设计得是否方便，直接决定了程序语言的描述效率。
我们来从简单到复杂考查集合运算的可能情况，看看好的 Lambda 语法都需要适应那些需求。

首先是直接使用集合成员的运算，比如计算集合成员的合计。
这是最简单的情况，采用普通的函数语法风格就可以，将待计算的集合作为参数传入，比如 sum(A) 用于计算集合 A 成员的合计，当然也可以使用对象式的语法风格写成 A.sum()。
这时候还不涉及 Lambda 语法，仅是把集合本身作为函数的参数。这个算第零条。

然后要能方便地在计算式中引用集合成员，作为第一条。
如果不是要计算集合成员的合计，而是要计算平方和，那么这个平方该如何描述？
这就要开始用到 Lambda 语法了，平方在这里本质上是一个函数，它以集合的当前成员作为参数，返回该参数的平方。Lambda 语法允许将某个函数以参数形式写进另一个函数，这样一条语句就搞定了，不必专门再定义这个函数。
但这里就有一个问题，在 Lambda 语法中用什么标识符或符号表示这个当前成员呢？
Java 等语言会像普通函数那样先定义参数名，这会让 Lamdba 表达式写得很臃肿，失去简洁性，不是个好办法。
对于这种极为常见的情况，用一个固定标识符或符号显得更简单。比如 SPL 中使用 ~ 表示当前成员，平方和就可以写成 A.sum(~*~)，简单易懂。也可以分两步做，先计算出集合成员的平方构成一个新集合，再计算新集合的合计，写成 A.(~*~).sum() 的形式。

但是，被认为有集合化特性的 SQL 中并没有使用某个符号或标识符来表示当前成员，那么 SQL 又是怎么解决这一问题的呢？
SQL 并没有普通意义上可由任何数据构成的集合。SQL 的集合就是表，表的成员是记录。SQL 有记录的概念，但并不能把记录作为一种数据类型来引用。如果我们要在 SQL 中针对一个单值成员的集合运算，也只能把单值理解为只有一个字段的记录，然后针对这些记录构成的表运算。所有计算都是针对某些字段的，而不能针对整条记录。
但这和 SQL 没有表示当前成员的符号有什么关系呢？
我们在讲集合化特性时还提到，面向结构化数据的 Lambda 语法要有简洁方式引用字段，SQL 就提供了可以直接引用字段的便捷机制，而 SQL 又只能计算字段，那就可以不必再提供引用当前成员（记录）的手段了。SQL 中计算平方和一定是某个字段的平方和，而整条记录作为集合成员时，计算平方和是没有意义的。
SQL 牺牲了集合的表达能力而简化了语法。但是，对于能够支持泛型成员构成集合的 SPL 来讲，~ 写法就是必要的了。
同时，如果用于结构化数据计算时，SQL 这种可以直接引用字段的写法也要得到支持才会方便，计算销售金额时总要写成 "~.price*~.quantity"，显然不如写成 "price*quantity“更简单直观。SPL 也提供了这样的支持，这也就是 Lambda 语法的第二条，面对结构化数据时可以直接引用字段。

第三，还要考虑嵌套引用时的规则
集合运算在本质上是一个循环，而循环语句可能多层嵌套，集合运算同样可能会嵌套。比如计算 A,B 两个集合的交集，简单的算法就是循环 A 的成员，看是不是在 B 集合中出现过，这就会涉及到两层循环。
这时候 ~ 写法就会产生歧义了，到底是指 A 集合还是 B 集合的当前成员，这需要在语法规则上做一个明确的约定。
一般可以采用就近原则，即如果没有指明 ~ 是哪个集合的，那缺省认为是内层集合的，而外层集合的当前成员则需要显式地指出其从属于哪个集合。遵循这个规则的 SPL，计算交集的表达式可以写成 A.select(B.count(~==A.~)>0)，其中的 ~ 缺省表示 B 的当前成员，而另一个要显式地写成 A.~ 以示区分。
面对结构化数据计算时可以直接引用字段名，也会产生内外层的歧义，也同样适用于就近原则。SQL 就是这样。当内外层表有相同字段名时，则缺省被认为是内层表的字段，引用外层表的同名字段时必须显式地写上表名；如果内外层表中没有相同字段名，则可以正确识别出来而不必书写表名。SPL 也支持这一规则。

SQL 在集合运算的 Lambda 语法设计上的总体表现不错，除了缺乏泛型成员的集合外，用于描述常规集合运算还是比较方便简捷的。SPL 拓展了 SQL 的数据组织，也就是引入了离散性，支持任意成员的集合，Lambda 语法也稍多了一些内容。