Action语义学综述

1. 简介

普通的编程人员都已经接受了形式化的语法描述(如BNF和它的变体),但是形式语义却不是这样.一般人都认为形式语义中那些奇怪的风格和数学符号使它只能被专家们使用,其实可以通过使用可读性更好的符号和风格来解决这个问题.

但是关于形式语义规范更深的问题是它们是建立在与我们理解编程语言完全不同的概念之上的.诸如控制流、存储、和绑定等概念仅仅是间接被指定的。在指称语义中它们依据数学函数来指定；在操作语义(普通的)中它们依据抽象机操作来指定。结果就是语义规范变得难以理解，对于大型的规范来说几乎是不可理解的。

Action语义是由Peter Mosses开发，并由David A. Watt进一步完善。一种语言的语义由行为（actions）来指定，它直接的反映了编程语言中一般的操作概念。因此就存在着这样一些原始行为，如：存储值、为标识符绑定值、测试布尔值等等。行为的组合就反映了顺序、选择、迭代的控制流。另外，这些行为使用了类英语符号来书写。这一切使得使用行为语义来描述的规范更容易阅读和理解。这些规范是模块化的，它们更容易反映编程语言的变化，并且可以在相关的语言规范中复用。

一种编程语言的action语义可以通过两层抽象来理解。上层是语言的规范，它是通过行为（actions）来表示的。底层是行为自身的规范。读者一般首先研究上层的规范。出于这个目的，行为在直觉上可理解就显得十分重要了。行为被设计成容易通过直接来理解。研究底层规范的目的也是为了满足用户这种直觉上理解的需求。

2. 背景

2.1. 指称语义

在程序设计研究人员中指称语义被广泛的使用，但是这个框架存在着一些问题，行为语义就是针对这些问题开发的，特别是对于一个实际的编程语言，指称语义尽管十分优雅和强大，但是对于像pascal和c这样规模的语言来说，语用问题却十分严重。

例如一个被描述语言的修改和扩展都要求对语义域的重新定义，原有的语义等式要求重新定义。另外的一个语用问题是很难从指称描述中发现诸如执行序列、绑定范围等基本概念。导致这些问题的原因主要有以下几点：

1．在一个指称描述中语义域的定义是全局可见的；

2．用算子来指定语义实体非常依赖域定义的细节；

3．所有的编程概念都被规约成纯函数；

那么如何来缓解以上的问题呢？

1．将指称描述模块化

2．引入符号，这些符号的定义而不是使用，需要在域中的指称物改变是改变；

为程序设计语言中的所有基本概念引入符号，例如：绑定的范围、值的存储、并发进程间的通讯等等。

3. 行为语义

行为语义的研究起源于指称语义。行为语义保持了指称语义的两大特点：

（1）使用上文无关文法来定义抽象语法树；

（2）使用语义等式来归纳定义组合语义函数，将语法树映射成语义实体；

在行为语义中有三类语义实体：action、data、yielders。其中主要实体是action,data和yielders是从属物。用来指定action及其附属语义实体的符号称为行为符号（action notation）。

action本质上是动态的可计算的实体。一个action的执行直接表示信息的处理行为，并且反映了计算的渐进性本质：action执行的每一步可能访问或改变当前的信息。Yielders是在action访问但是没有改变信息时发生，对Yielders的评估导致一个data实体产生(包含了一个特殊的实体来表示未定义)。

3.1. 行为语义描述（ASD）

一个行为语义描述（ASD）由三个主要部分组成，分别用来指定抽象语法、语义函数和语义实体，并将其指定成相互分离的模块，在一个大的规约中它们有可能被分成子模块。就像我们把文章分成节小节一样。每一个模块都有标题，并且它必须是自包含的。从这个意义上说在某个模块中使用一个完整的符号必须在那里定义。当然如果一个模块要使用在模块中定义的符号，并不需要再中再次逐字的定义，只需要通过的标题来引用即可。相似的是一个子模块使用模块中的公共符号时。我们也只在模块中指定符号一次，然后在它的子模块中继承即可。一个行为语义描述的模块化结构定义如下：

Abstract Syntax

Semantic Functions

Need： Abstract Syntax, Semantic Entities

Semantic Entities

一般说来模块的标题应该反映模块的目的。抽象语法模块和语义实体模块是自包含的，并且能够独立的使用。另一方面，语义函数模块需要使用另外模块中引入的符号。

这有助于语义描述的模块化划分。例如我们可以把抽象语法（Abstract Syntax）模块划分成表示表达式、声明的子模块。这样的划分也可以用在相应的语义函数（Semantic Functions）模块上。我们可以把语义实体（Semantic Entities）划分成处理数字、数组、过程的子模块。这些子模块只需要进行很小的修改就可以复用在其它的语义描述中。

模块的细分不要求改变对已经规约的模块的引用。一个模块的引用隐含这引用这个模块的所有子模块，然而任何新的子模块之间的依赖关系必须指定，当然这有可能会使细分工作变得十分复杂。我们把的子模块记为

我们允许模块之间的相互依赖，它们之间的顺序并不重要。例如：在抽象语法中过程的declarations与 statements相关，而statements块又涉及到declarations，这反映到模块中就是相互依赖的。与此类似的是语义等式的相关部分。以前的模块框架都强调严格的继承关系，从而禁止了相互依赖。

与此相关的是我们可以以最方便读者的方式自由的陈述模块。在语义描述中最可取的陈述方式是抽象语法最先，然后是语义函数，最后是语义实体。这里假设语义实体是经过精心选择的，而且对它的解释十分依赖与它所使用的符号，如果语义实体在语义函数前出现的话，就难以独立于它的用途而认识它。

当然我们可以更灵活的安排它们的次序，因为它们的次序对于它们所指定的实体完全没有影响。我们可以通过将数个不完整的模块进行组合来逐步的完善一个模块。为了清晰起见，一个模块如果和前一个模块具有相同的名字，那么就应该显示的说明后一个是前一个的延续，例如我们可以在一个模块中引入一个符号，然后在另一个具有相同名字的模块中指定它最本质的属性。可以实现与此类似功能的还可以使用扩展子模块（extra submodule），当然这有可能使得模块之间的依赖关系变得复杂。

一个极端的不完整规范的例子就是仅仅只给出了模块的结构，而将整个实体符号的定义放到了另外一个模块中去，例如我们上面所给的ASD就是这样一个良定义的不完整规范。这样一种大纲的形式在一个规范中涉及到许多模块时就特别有用。

最后，我们介绍几种指明一个模块是另一个模块的子模块的标记法。对于小规模的规范来说，锯齿形的排列就足以说明这种嵌套关系了，对于大型的规范来说，使用这样一种形式，其中是顶层模块。或者使用，是第n层模块的标题，允许在两段形式化的规范之间插入一段非形式化的文字，读者可以根据字体的不同将它们区分，这在其他的形式化框架中很难做到。

3.1.1. 抽象语法

程序设计语言的参考手册一般都是使用形式化的上下文无关文法，扩展的正规表达式来规约具体的文法。一个形式文法包含了一组产生式，涉及一些终结符和非终结符。形式化文法具有很好的语用性，例如可读性、可修改性。抽象文法也采用了以上这些概念。

3.1.2. 语义函数

在action语义中，我们使用语义等式来规范语义函数。每一个等式依据语义实体来定义一个短语的特定类型的语义。语义函数中的成分在语义等式中是十分明显的。

在数学的意义上说，一组语义等式，就是一个简单的归纳定义，它将语法映射成语义。也可以将其单纯的看成是一种规范，套指定了如何将程序设计语言中的语法翻译成语义实体的符号。

一个语义函数总是有一个语法参数，并且产生一个语义实体。用来指定语义函数的符号可以自由选择，语义函数的右边是action语义中action和data的标准符号，它们都是形式化的。

3.1.3. 语义实体

3.1.3.1. ACTIONS

一个action的执行有可能是一个封闭action的一部分，分别是：completes，代表了正常的终止；escapes，代表了异常终止；fails，表示放弃了一个选择；或者diverges。Action可以用来表示程序的语义：action的执行代表了程序的可能行为。此外，action还可以用来表示组成程序的一些成分，如声明、表达式等。

一个action可以是非确定的，在一个相同的初始信息的情况下可以用不同的执行。非确定性表示了于实现相关，程序的执行有可能随着实现方式的不同或者实现方式相同而时间不同而不同，Action执行时所处理的信息可以分成以下几类：

- transient: 代表了中间结果;

- scoped: 将符号绑定到数据，代表了符号表；

- stable: 存储单元中的数据，表示将值赋给了变量；

- permanent: 在分布式的action中传递的数据；

Transient 信息是在action是在临时使用时可得的。相反，Scoped一般会在整个action中有效，尽管有可能被subaction屏蔽。Stable 可以改变当时不能被屏蔽，它会一直持续直到被销毁。Permanent甚至不能被改变，只能被扩展。当一个action被执行，transient只能是在completion或escape的情况下才是可得的。一个scoped信息只能在action完成（completes）的情况下产生。相反对stable的改变和对permanet的扩展只能在action执行时完成。

信息不同的类型导致了所谓的action刻面（facet）产生，刻面在某一时刻最多只处理一类信息：

- basic刻面, 独立的处理信息（控制流）;

- functional刻面, 处理transient类型的信息 (actions受到或提供数据);

- declarative刻面, 处理scoped类型的信息(actions 接受或处理绑定);

- imperative刻面, 处理stable类型的信息(actions 分配或回收存储单元并修改存储单元中的数据);

- communicative刻面, 处理 permanent类型的信息 (actions在缓冲区中发送或接受消息,并为agents提供契约).

这些刻面都是独立的。例如改变一个存储单元中的值不会影响到涉及这个存储单元的绑定。

标准的action符号由原子action和action组合子（combinator）组成。每一个原子action都是单一刻面的，只在一个刻面影响信息，尽管它所包含的yielders有可能会涉及到不同类型的信息。

Action组合子决定了组合action的每一个刻面的控制流和信息流，它允许表达多刻面的action，例如一个action不光要求分配一个存储单元，还要求为这个存储单元赋予标识。

只有function刻面的action与数学上的纯偏函数对应紧密，差别在于这个action的执行有可能是escape、fail、completing和deverging。

3.1.3.2. DATA

Action处理的信息由数据项组成，它们经过组织后可以对单个的数据项进行访问。DATA可以包括若干相似的数学实体如：布尔值、数字、字符、字符串、表、集合以及图。它也可以包含纯粹用于计算的实体，如标记、单元和agents等。Action本身不是data，但是它们可以合成一体，就是所谓的abstractions，这是data，并且也可以作为action使用。新的data类型就可以这样引入以反映特殊的信息。

3.1.3.3. YIELDERS

Yielders是这样的一种实体，action可以在执行是对其进行评估（evaluate）以产生data，所产生的data依赖于当前的信息，例如，给定的临时信息，所接受的绑定，缓冲区的状态等。评估不会影响当前的信息。对yielders的数据操作的应用可以生成复合的yielders。

4. 前景

我们已经介绍了action 语义的基本理论，下面我们介绍一下关于它的研究前景：

首先，继续要开发一个关于action的communicative刻面的基于异步通讯和消息传递的证明算子。

另外，需要开发一个统一的action符号集以及是否考虑是否将“Yielders”作为一个子action类型。

第三，目前还不清楚是否允许使用action语义的用户改变action符号的操作语义，或者添加新的action组合子和原子action，如果允许这样做，那样就需要对所有的action符号规则再次进行证明。当前的action符号的结构化操作语义难以进行修改，选择另一种操作语义也许是不错的选择。

4. 结论

对比指称语义，我们可以发现action语义在以下几个方面是成功的：

－正确性：action语义描述符易读，故可以避免绝大多数错误。

- 可理解性: 在实践中指称语义描述的可理解性比较差，即使将其中的希腊字母换成有意义的符号依旧如此，而action语义描述符则可以被一般的程序员所理解。

- 模块化: 指称语义描述中没有模块化的思想，所以在语义域或描述风格的改变都要对整个语义等式进行改变。而action语义描述符是高度模块化的。

- 可扩展性: 由于上面所说的原因，指称语义没有能力描述一个大型的语言，而action语义却可以比较容易的做到这一点。

参考文献

1. P. D. Mosses. Denotational Sementics, Handbook of Theoretical Computer Science,Volume B, Chapter 11. Elsevier Science Publishers, Amsterdam; and MIT Press, 1990.

2. D. A. Schmidt, Denotational Semantics: A Methodology for Language Development, Allyn & Bacon, 1986.

3. J. E. Stoy, Denotational Semantics: The Scott-Strachey Approach to Programming Language Theory, MIT Press, 1977.

4. J. Alves-Foss, editor. Formal Syntax and Semantics of Java, volme 1532 of Lecture Notes in Computer Science. Springer-Verlag, 1999.

5. J. Alves-Foss and F. S. Lam. Dynamic Denotational Semantics of Java, P201 – 240. Springer- Verlag, 1999.

6. E. Borger and W. Schulte. A Programmer Friendly Modular Definition of the Semantics of java, p353-404, Springer-Verlag, 1999.

7. J. Gosling, B.Joy, and G. Steele, The Java Language Specification. Addison-Wesley, 1996.

8. S.B. Lassen, P. D. Mosses, and D. A. Watt, An introduction to AN-2: The Proposed New Version of Action Notation, Digital Fountain, San Francisco, BRICS & Dept. of Computer Science, U. of Aarhus, Denmark, Dept. of Computer Science, U. of Glasgow, Scotland, 2000