Question

我正在使用Menhir解析DSL。我的解析器使用精心设计的嵌套类型集合构建AST。在以后的类型检查和为用户生成的错误报告中的其他传递期间，我想参考它发生的源文件位置。这些不是解析错误，它们是在解析完成后生成的。

一个天真的解决方案是为所有AST类型配备额外的位置信息，但这将使得与它们一起工作（例如构建或匹配）不必要的笨拙。这样做的既定做法是什么？

Answer 1

我不知道它是否是最佳做法，但我喜欢在Frama-C系统的抽象语法树中采用的方法;见https://github.com/Frama-C/Frama-C-snapshot/blob/master/src/kernel_services/ast_data/cil_types.mli

这种方法使用＆＃34;层＆＃34;彼此嵌套的记录和代数类型。记录包含元信息，如源位置，以及代数＆＃34;节点＆＃34;你可以匹配。

例如，这是表达式表示的一部分：

type ...

and exp = { 
  eid: int; (** unique identifier *)
  enode: exp_node; (** the expression itself *)
  eloc: location; (** location of the expression. *)
}

and exp_node =
  | Const      of constant              (** Constant *)
  | Lval       of lval                  (** Lvalue *)
  | UnOp       of unop * exp * typ
  | BinOp      of binop * exp * exp * typ
...

因此，给定e类型的变量exp，您可以使用e.eloc访问其源位置，并在e.enode中的抽象语法树上进行模式匹配。

如此简单，＆＃34;顶级＆＃34;语法匹配非常简单：

let rec is_const_expr e =
  match e.enode with
  | Const _ -> true
  | Lval _ -> false
  | UnOp (_op, e', _typ) -> is_const_expr e'
  | BinOp (_op, l, r, _typ) -> is_const_expr l && is_const_expr r

要在表达式中更深入地匹配，您必须在每个级别查看记录。这会增加一些语法混乱，但不会太多，因为你可以只对你感兴趣的一个记录字段进行模式匹配：

let optimize_double_negation e =
  match e.enode with
  | UnOp (Neg, { enode = UnOp (Neg, e', _) }, _) -> e'
  | _ -> e

为了比较，在没有元数据的纯AST上，这将是：

let optimize_double_negation e =
  match e.enode with
  | UnOp (Neg, UnOp (Neg, e', _), _) -> e'
  | _ -> e

我发现Frama-C的方法在实践中运作良好。

Answer 2

您需要以某种方式将位置信息附加到您的节点。通常的解决方案是将AST节点编码为记录，例如，

type node = 
  | Typedef of typdef
  | Typeexp of typeexp
  | Literal of string
  | Constant of int
  | ...

type annotated_node = { node : node; loc : loc}

由于您正在使用记录，因此您仍然可以在没有太多语法开销的情况下进行模式匹配，例如，

 match node with
 | {node=Typedef t} -> pp_typedef t
 | ...

根据您的表示，您可以选择单独包装您的类型的每个分支，包装整个类型，或递归，如@Isabelle Newbie的Frama-C示例。

类似但更通用的方法是扩展不包含位置的节点，但只使用唯一标识符，并使用最终映射向节点添加任意数据。这种方法的好处是，您可以在实际外部化节点属性时使用任意数据扩展节点。缺点是您实际上无法保证属性的总体，因为有限地图不是总数。因此，保存例如所有节点都具有位置的不变量更加困难。

由于每个堆分配的对象已经有一个隐式的唯一标识符，即地址，因此可以将数据附加到堆分配的对象而不实际将其包装在另一种类型中。例如，我们仍然可以使用类型node并使用有限映射将任意信息附加到它们，只要每个节点都是一个堆对象，即节点定义不包含常量构造函数（如果有，你可以通过添加伪单位值来解决它，例如，| End可以表示为| End of unit。

当然，通过说一个地址，我并不是指对象的物理或虚拟地址。 OCaml使用移动的GC，因此在程序执行期间OCaml对象的实际地址可能会发生变化。而且，地址通常不是唯一的，因为一旦对象被解除分配，其地址就可以被完全不同的实体抓取。

幸运的是，在将ephemera添加到最新版本的OCaml之后，它不再是一个问题。此外，一个ephemeron将与GC很好地协作，因此如果一个节点不再可达，它的属性（如文件位置）将由GC收集。所以，让我们以一个具体的例子为基础。假设我们有两个节点c1和c2：

let c1 = Literal "hello"
let c2 = Constant 42

现在我们可以创建从节点到位置的位置映射（我们将后者表示为字符串）

module Locations = Ephemeron.K1.Make(struct
   type t = node
   let hash = Hashtbl.hash (* or your own hash if you have one *)
   let equal = (=) (* or a specilized equal operator *)
end)

Locations模块提供典型命令式哈希表的接口。所以让我们使用它。在解析器中，无论何时创建新节点，都应在全局locations值中注册其位置，例如，

let locations = Locations.create 1337


(* somewhere in the semantics actions, where c1 and c2 are created *)

Locations.add c1 "hello.ml:12:32"
Locations.add c2 "hello.ml:13:56"

之后，您可以提取位置：

# Locations.find locs c1;;
- : string = "hello.ml:12:32"

如您所见，虽然解决方案在某种意义上是好的，但它不会触及节点数据类型，因此您的代码的其余部分可以很方便地匹配它，它仍然有点脏，因为它需要全局可变状态，这很难维护。此外，由于我们使用对象地址作为键，因此每个新创建的对象（即使它是从原始对象逻辑派生的）都将具有不同的标识。例如，假设您有一个函数，可以规范化所有文字：

let normalize = function
  | Literal str -> Literal (normalize_literal str)
  | node -> node

它将从原始节点创建一个新的Literal节点，因此所有位置信息都将丢失。这意味着，每次从另一个节点派生一个节点时，您需要更新位置信息。

ephemera的另一个问题是它们无法在编组或序列化中存活下来。即，如果将AST存储在某个文件中，然后将其恢复，则所有节点都将失去其身份，location表将变为空。

说到你在评论中提到的“monadic方法”。虽然monad是神奇的，但他们仍然无法神奇地解决所有问题。它们不是银子弹:)为了将某些东西附加到节点，我们仍然需要使用额外的属性来扩展它 - 直接的位置信息或我们可以通过其间接附加属性的身份。 monad可能对后者有用，因为我们可以使用状态monad来封装我们的id生成器，而不是对最后分配的标识符进行全局引用。并且为了完整起见，您可以使用UUID而不是使用状态monad或全局引用来生成唯一标识符，而是获取不仅在程序运行中唯一的标识符，而且在某种意义上它们也是通用唯一的无论您运行程序的频率如何（在理智的世界中），世界上没有其他具有相同标识符的对象。虽然看起来生成UUID并不使用任何状态，但它仍然使用命令式随机数生成器，所以它有点作弊，但仍然可以看作是纯函数，因为它不包含可观察的效果。

menhir - 将AST节点与源文件中的令牌位置相关联

2 个答案: