在x这个集合中的S,只是数据，而并不应当包括S的操作。这是考虑到S本身不能再有任何的依赖——包括时间，因此它必须是一个含义与可操作性都非常明确的状态值。若使S,与其操作都存在于同一个集合中，则它们必须只能是一个可分布系统的“数据全集x₂”的一部分，并且该系统的数据集x₂中也就存在相对应的S。。

作出这一点限制才可以使x作为一个独立概念加以考察，并且可以将“数据”与“数据的状态”在概念上有效地区分开来。由于任何状态□本身也是数据□也能被作为数据复合到一个“数据全集”中去□也能存有其确定的操作因此我们可以在程序中传递它、处理它，而不是视其为一个状态。

作为“状态”本身，S,在现在或将来，或是在“数据全集”的任意一个持有者手中，都必须以及必然是含义与可操作性完全明确的。例如，它仅仅是一个“0、1”状态，它的操作仅有唯一的“逻辑非”操作。当然，状态可能更为复杂，但只要有与之相应的、明确的、完整的逻辑，并且这些逻辑可以独立于这一状态，可以由不同的持有者实现，我们都可以将这样的状态称为Sx。

①此前我们已经讨论过“计算的不确定性是对机器计算是否有价值的终极拷问”这一问题。它既是我们能通过“计算机语言”进行机器计算的基础，也是使得我们能够正确地将这样的计算应用于一个“数据全集”的基础。②我们稍后会再来讨论这一限制的实际含义。

数据依赖在概念上只表明多个逻辑作用于同一个数据，它最终将被表达为面向{x,x",S}的操作，其中{x',x"}表明被依赖的数据与其可确定的行为，而{S}表明一个有明确含义与可操作性的状态。

但我们并没有限制"多个逻辑"之间的时序关系。也就是说，数据依赖只用“状态"来表明：多个逻辑与数据的全集x都存在关系，但并不表明是一个并行系统下的关系，或是一个串行系统下的关系。例如，“(对同一数据的)多读单写”显然是数据依赖的，但在多读时多个逻辑之间是并行的，而在单写时它们却是串行的。yipindushu.com

在我们的定义中，所谓“并发多任务”系统，是面向数据依赖的一个实现。例如，上述“多读单写”系统是可以依赖针对于某个状态的一组逻辑来实现的。更确切地说，所谓"并发模型",其实就是：□对上述状态定义一个操作集，并□在多个逻辑中实现该操作集。

【我们为什么需要状态?】

事实上我们是把两种时序依赖都最终归结于“数据依赖”,进而将这种依赖关系委托于这个“(数据全集中的)状态”。并且，我们要求状态本身只是纯粹的数据，而将状态的相关逻辑视作公共规约。我们其实是在讨论如图3-15所示的模型：SteplStep2StepN{x',x"}状态图3-15将状态从纯数据中剥离，并讨论与逻辑步骤(Step)间的关系这一模型的本质仍是基于“逻辑作用于数据”这一思想。也就是说，它是基于命令式语言设计范式：我们将状态{S}视为{x,x"}的操作句柄，并通过某种规则在Step1,.…,StepN之间传递该句柄的执有权(类似于一种令牌)。

既然S的抽象含义要求“含义与可操作性”明确，同时我们也知道，函数既包含一个数值含义的传出，也包含可操作性明确的逻辑，可见函数在抽象概念上是满足“状态”的两个要素的。那么，S,本身为什么不能是一个函数呢?问题仅在于，“状态”作为数据含义时是与{x,x"}相关的，而“函数”作为数据含义时是指它的传出。也就是说：function foo(){return 5;3|}可以在数据上表明：foo = 5消息但这也导致我们无法通过return来表明foo()这个函数的(数据含义的)状态。解决这一问题的方法，就是消息。例如：function foo(){send(bar,'...')return 5;4 }这个例子中，foo()向bar()发送了一个消息…,这个消息用于指明foo当前所持有的数据的某个状态。由于foo()可以持有多个数据——多个数据全集，或者由多个子集构成的集合——所以它也可以发送一个复合信息的消息，或用某个单一消息来指示所有数据的状态。

【二】

我们看到，消息本身跟状态是同义的——具有明确的“含义与可操作性”,只是在函数(以及函数式语言设计范式)中，接收者可以视为发出者一定持有了{x'x”},并通过消息M来通告了上述数据的状态?。

消息发布与处理，成为多个函数之间的一种关系，