对于状态，Peter Van Roy是将它作为多种范式中对数据的不同理解来看待的⑤:状态是记忆信息的一种能力，更精确地说，是及时存贮值序列的能力。它的表现能力极大地受到其所在范式的影响。我们将其表现能力划分出四个等级，它们的不同在于状态是未命名的或命名的、确定的或非确定的，以及串行的或并发的……非确定性对真实世界中的交互很重要(例如在“客户端/服务器”编程模型中),而命名状态则对模块化有着相当重要的意义。

在这一观念中，状态是一个可变的数据：表达某个存储位置上、某时的信息。换言之，数据的不确定性——包括其静态的确定性—表现为状态。这使得状态在概念上很类似于变量，不过这也并没有什么不妥，毕竟在大多数语言中，我们的确是用变量来实现状态以及相关的机制。基于此，Peter Van Roy非常深入地剖析了状态的数据性质。

把Peter Van Roy的思考逆向探讨一番，我们可以得出这样一个结论：当不考虑一个存储位置上的命名特性时，它就既非变量或常量，也非某个确定的运算对象(例如“对象"等高级的抽象概念),而只是一种更加泛义的“状态”;同时存储这个状态本身的事物，由于没有位置、时序等概念，所以借用我们之前使用过的名词，可以称之为"cells"。

①在从变量到常量的概念变迁中，某些语言并不引入“常量”这一概念，而是通过强调“变量不可写”来强制数据必须具有确定性。在类似的语言范式(例如数据流范式)的基础观念中，通常还涉及变量仅作为标识符而未有确定值时的抽象。例如在Oz与MapReduce中，如果一个变量尚未绑定值，则它将阻止运算它的函数与任务(job或process),因为这时的运算也是不确定的。直到该变量存在一个确定值，阻止才得以解除。

②这里的协同分布是指：未必一致，但至少是通过某种规则来约束。③引自Peter Van Roy对“主要编程范式”一图的说明。参见：www.info.ucl.ac.be/~pvr/paradigms.html一旦我们不考虑这个存储位置(cells)本身的物理限制，而只考虑其中数据本身的、值的含义时，我们也就可以脱离系统(例如某个系统的多个子系统)地称之为“消息"。消息既是系统之间的约定，也可以视为是游离于系统之间的、借着这些约定来约束系统的数据。

综上所述，状态与消息的抽象概念的区别在于：前者往往带有位置之于存储，或数据之于逻辑的含义；后者则将位置与逻辑含义都抽取掉，只认为消息是一个约定所需的数据部分。图3-18表达了二者的关系①。yipindushu.com

其中，对于消息：□其数据规格部分是应用中的所需，而非概念上的必需；□约定所需的逻辑部分是由其他系统根据约定实现的；□约定(在概念上)是可遵守、可更新，以及可违约的。

既然其约定是一个非数据的规约，是系统间在逻辑实现上的约束，并且事实上这一约束也可能不被遵守，所以可以说：消息就是消息，消息没有任何特定含义的性质。

①该图也从侧面表达了变量与状态在数据性质上的相似性，以及在结构化程序设计和面向对象程序设计中“可以以结构、对象等类型化数据来实现状态”这一事实。

煮鸡蛋，大概是最简单的美食了。这个世界上已知的最完美而又同时是最简单的煮鸡蛋方法就是：把鸡蛋和水放在锅里，煮。

有两个极简单但不强制的限定条件：其一，水要漫过鸡蛋；其二，烧火的时间要够把鸡蛋煮熟。所谓“不强制”,是指在大多数情况下：水不漫过鸡蛋也是可以的，只要别煮干；而鸡蛋煮得不是很熟，或者多煮了一些时间也没关系。

而且，煮一锅鸡蛋与煮一个鸡蛋的方法和限制条件居然是完全一样的!这意味着，我们煮鸡蛋的算法以及作为数据的鸡蛋，乃至煮鸡蛋所需的整个系统，天生就是支持完美分布的!

但问题是，你并不能确保做好这份美食。