【口Step1与Step2之间的时序关系与数据依赖关系是不明确的：所有类似的关系】

① return既已用于表明foo的数据含义，则必然无法用于表示“含义与可操作性确定的、foo()的整体含义”。即它不能既表示foo(的部分含义，同时又表示foo()的整体含义。这种“既是又非”有违于基本逻辑的矛盾律。

②我们用到了“通告”这个词，意味着消息的发布可以是单个的，也可以是多个的。前一种情况可以实现令牌式的同步，后一种则可以实现多读单写式的同步。

与依赖变成了它们之于消息M的处理规则，亦即是更复杂的逻辑①;口数据之间的关系被彻底屏蔽了：Step2并不依赖Stepl的任何数据，包括它的入口数据或出口数据。

表面上看，消息类似于调用，例如我们可以将Stepl与Step2之间的关系看做：function Step1(){Step2()4 ]一方面，这种类似“调用关系”的形式的确意味着Step2在时序上依赖Stepl;但另一方面，在我们讨论的消息中，实际并没有“调用”这层关系。也就是说，Stepl向Step2发出消息M之后，就可以异步地执行自身的逻辑了，并不需要等待Step2的执行，也不依赖Step2的结果数据。yipindushu.com

消息并没有类似回调的性质，尽管消息可以实现这一性质。Stepl发出消息M这一行为，并不表明Step2必然执行某种由Stepl决定的逻辑(例如回调函数),也并不表明消息M是某个函数的数据依赖。

消息也没有类型与结构的约束。一个消息以何种复杂程度的方式来记录消息体，是Stepl与Step2之间或者Step2与StepN之间的约定。除了约定的双方或多方对规则的强约束外，消息本身并不存在语言层面或计算机系统层面的约束。因此，基于消息的模型很容易适应复杂的计算环境。

状态与消息其实是一个统而一之的东西，它们不过是两个程序设计范式对同一事物的不同叙述。这样我们又回到了最初讨论问题的方式，即“两个侧像”。

回顾此前的讨论，我们曾经设定数据的全部性质中有一个不可或缺的子集为标识、值和确定性。其中值是数据的本义，标识是人与计算机进行沟通时所需的抽象定义，确定性则是数据与使用这些数据的计算系统的最终极的问题。基本上，我们可①这些逻辑基于M的数据含义，即{m',m"},它被Step2作为私有的数据信息加以处理。②同样地，当Step2发出消息N时，N与M,或N与{m,m”}并没有必然关系。

③这意味着，“发出消息”对于Step1来说是一个“有确定结果的确定行为”。这一确定结果是“没结果”,因为在Step1中不存在对这一结果任何有意义的依赖。而“函数调用”正好是存有对某种结果的依赖的。

④这是程序设计语言的需求，即标识符(token)、名称(name)或词(word/keyword)的本义。⑤在之前的种种讨论(事实上也包括接下来的讨论)中，凡涉及对“数据性质中的确定性”的追问，必然会对我们在计算模型、语言范式等方面提出新的挑战。

+存储，变量+确定性常量图3-17 数据在计算机语言中的种种抽象与概念递进关系但是我们上面讨论的状态，是否需要全部三个性质呢?这一设问的关键在于：我们将状态S,作为数据全集x的一个分量，就意味着S的三种性质与x的其他分量x'、x"必须是协同分布的②。因此设问若成立，就意味着任意一个数据在其分布过程中都要保证这三种特性的协同分布。例如数据A,其分布为A1,…,A,在同一时刻Aj,…,A,都必须是同时确定的，或同时不确定的。又例如——以其字面上的含义来看——我们必然面临类似的需求：在一个分布系统中的多个子系统中，要求同一个状态使用完全相同的标识。