列表去重memq、r函数改造为stream版本的潜在问题问询

首先先明确原列表版本的已知笔误，这些缺陷在改造时如果没被修复会被Stream版本继承：

• 原memq实现的递归分支错误调用了mem而非memq
• 原去重函数r中scdr应为cdr，最后一个分支的cdr last应为cdr lst
• 原逻辑的去重规则是保留元素最后一次出现的实例，而非通常预期的第一次出现的实例

改造后的Stream版本专属潜在问题 #

1. 无限流场景下直接死锁 #

当前的去重逻辑要求先判断当前元素是否存在于后续的所有流元素中，这个判断是立即求值的，不会被cons-stream的惰性特性优化。如果输入是无限流，memq会永久遍历后续的无限元素，永远无法返回判断结果，整个函数会卡住，连第一个元素都无法输出。

;; 示例：传入无限1流时，函数永远不会返回任何结果
(define ones (cons-stream 1 ones))
(r ones)

2. 无记忆化流场景下的性能灾难 #

Stream的核心是惰性求值，如果使用的是不带记忆化的delay实现（即仅延迟计算，不缓存计算结果），memq每次遍历stream-cdr都会重新计算一遍之前的流元素。对于长度为n的流，时间复杂度会从列表版本的O(n²)恶化为至少O(n³)，流长度稍大就会出现严重的性能问题，且调试难度远高于普通列表。

3. 空流判断的兼容性问题 #

不同Scheme实现对空流的定义存在差异：部分实现沿用空列表'()作为空流，还有部分实现使用单独的stream-null作为空流标识，配套的判空函数是stream-null?。当前实现直接用null?判断流是否为空，在使用stream-null的实现中会直接判定所有非空流为空，函数直接返回空结果，完全无法正常工作。

4. 问题排查难度大幅提升 #

原实现使用eq?做相等性判断，对于流中存在的数值、字符串等非符号类型的元素，eq?的判断结果和预期的相等性会存在差异。这个问题在列表版本中就存在，但因为流的惰性特性，问题不会在调用函数时立即触发，只会在访问到对应流元素时才报错，排查成本远高于普通列表。

内容的提问来源于stack exchange，提问作者ili