Scheme报错：Application Not a Procedure，定位cond表达式问题

首先，咱们来拆解你遇到的问题：你提到的“把值当作函数调用”的错误，根源并不是cond的格式问题，而是你的函数返回值类型不一致，且部分返回值是字符串/数字这类非函数值，如果后续代码把这个返回值当作函数来调用（比如不小心加了多余的括号），就会触发这个错误。另外，你的函数逻辑也有可以优化的地方，咱们一步步理清楚：

你的代码里的核心问题 #

先看你的函数返回值：

• 当l是空列表时，返回字符串""
• 当l是单元素列表时，返回数字0
• 其他情况返回递归调用的结果（最终还是会落到上面两种情况之一）

这种不一致的返回值很危险——如果你的代码里不小心把insert_labels的返回值用括号包裹（比如写成((insert_labels my-list))），就会把""或者0当作函数来调用，这正是你遇到的错误。

另外，你的目标是遍历列表并修改哈希表（用了hash-set!的副作用），其实不需要返回这些奇怪的值，统一返回一个合理的“结束标记”会更安全。

修正后的代码 #

我们可以调整返回值，同时优化递归的终止条件，避免递归到空指针的问题：

(define insert_labels 
  (lambda (l)
    ;; 终止条件：空列表直接返回（返回#t表示处理完成）
    (cond
      [(null? l) #t]
      ;; 处理单元素列表：不需要递归，直接返回
      [(null? (cdr l)) #t]
      ;; 如果当前元素是other类型，存入哈希表后递归处理剩余列表
      [(eq? (what-kind (car l)) 'other)
       (hash-set! label_hash (car l) (cadr l))
       (insert_labels (cdr l))]
      ;; 其他情况直接递归处理剩余列表
      [else (insert_labels (cdr l))]
    )
  )
)

关键修改点说明 #

1. 统一返回值：所有终止条件都返回#t（布尔值，表示处理成功），递归调用也会最终返回#t，这样即使后续不小心误操作，也不会把返回值当作函数调用（布尔值不是函数）。
2. 优化终止条件：用(null? (cdr l))判断单元素列表，比(eq? (cdr l) '())更符合Scheme的惯用写法（null?是专门判断空列表的谓词）。
3. 移除不必要的返回值：既然你的核心操作是修改哈希表的副作用，函数不需要返回字符串或数字，返回一个明确的成功标记更清晰。

额外提示 #

如果你之前的错误是因为在调用insert_labels时多加了括号（比如((insert_labels my-list))），那只要去掉多余的括号，写成(insert_labels my-list)就可以了——这也是“把值当作函数调用”错误的常见原因：把非函数值用括号包裹，强制当作函数来调用。

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