函数参数并非函数颜色

一篇发表在Hacker News上的文章对编程中"函数颜色"这一概念进行了深入探讨，区分了函数参数变更与真正色彩变更之间的本质差异1。作者将色彩定义为一种强制性的变更依赖关系，一旦引入就必须迫使整个调用栈中的所有函数都做出相应改变，而普通的参数变更则可以被中间函数所封装和隔离1。

在Go语言中，context.Context经常被视为潜在的色彩，因为一旦使用就应该传递给所有后续函数1。然而作者指出，由于Go中任何函数都可以通过调用context.Background()来适配新的context参数，这实际上打破了完全的色彩链式关系1。相比之下，Haskell的STM单子则被列为部分色彩的例子，通过类型系统强制STM操作只能在IO上下文中执行1。文章强调，普通变更虽然可能链式传播，但往往被中间函数封装，而真正的色彩变更则会绕过中间函数直接强制整个调用栈做出反应，无法被封装1。

An article published on Hacker News examines the programming concept of "function colors" and distinguishes it from ordinary changes to function parameters 1. The author defines color as a type of dependency change that mandates all functions in the call stack to adapt accordingly, whereas standard parameter modifications can be encapsulated and isolated by intermediate functions 1.

The distinction becomes clear through practical examples 1. Go's context.Context is often treated as a potential color because once adopted, it should be passed to all subsequent functions in the call chain 1. However, the author argues that not all function parameters constitute true colors, noting that any Go function can invoke context.Background() to adapt to a new context parameter, thereby breaking a complete color-enforced relationship 1. In contrast, Haskell's STM monad represents a partial color implementation, where the type system enforces that STM operations can only execute within an IO context 1.

The core insight is that ordinary changes typically affect only direct callers and may propagate through chains but are often encapsulated by intermediate functions, while true color changes bypass intermediate functions and force reactions across the entire call stack without possibility of encapsulation 1.