21

阅读并观看此演示文稿： http
://boost-spirit.com/home/2011/06/12/ast-construction-with-the-universal-tree/ 我发现了这个声明——基本上我们建议不要使用语义动作。

我必须承认，我已经感受到了类似的感觉：带有语义动作的语法实际上看起来有点难看。而且，当我需要扩展/更改它们时，需要大量的“微观管理”来精确地使用语义操作。演示文稿中演示的属性语法方法似乎更加优雅和有前途。

所以我想问：这是“官方”观点吗？我应该学习如何使用属性语法并更详细地避免语义动作吗？如果是这样——我想要求一些基本的（甚至可能是微不足道的）示例，展示这种方法——LISP 解释器太复杂了，我无法咀嚼......

4

1 回答 1

28

我相信哈特穆特会在一秒钟内回答。到那时，这是我的看法：

不，这不是官方观点。

语义动作有一些缺点

  • 语义动作最简单的缺点是关注点分离的风格概念。你想在一个地方表达语法，在另一个地方表达语义。这有助于可维护性（尤其是关于编译 Spirit Grammars 的冗长编译时间）

  • 如果它们有副作用（通常是这种情况），则会产生更复杂的影响。想象一下当语义动作有副作用时从解析的节点回溯：解析器状态将被恢复，但外部效果不会。

    在某种程度上，仅使用属性就像在函数式程序中使用确定性的纯函数一样，当程序仅由纯函数组成时，更容易推断程序（或者，在这种情况下是语法状态机）的正确性。

  • 语义动作倾向于（但不一定如此）通过价值引入更多的复制；这与大量回溯相结合，可能会降低性能。当然，如果语义动作很“重”，这本身就会阻碍解析的性能。

语义动作适用于各种目的。事实上，如果您需要解析具有上下文敏感性的重要语法，您就无法逃避它们。

  1. 考虑使用qi::locals<>和继承属性（来自Mini XML - ASTs!示例的代码） - 它们涉及语义操作：

    xml =
        start_tag                   [at_c<0>(_val) = _1]
    >>  *node                      
    >>  end_tag(at_c<0>(_val)) // passing the name from the 
                               // ... start_tag as inherited attribute
;

    或者使用 qi::locals：

    rule<char const*, locals<char> > rl;
rl = alpha[_a = _1] >> char_(_a); // get two identical characters
test_parser("aa", rl); // pass
test_parser("ax", rl); // fail

    IMO，这些语义动作通常不会造成什么问题，因为当它们被回溯时，下一次执行通过（相同的）语义动作时，本地将被新的正确值覆盖。

  2. 此外，有些工作确实是“快速而肮脏”的，不保证使用utree或手动 AST 类型：

     qi::phrase_parse(first, last, // imagine qi::istream_iterator... 
     intesting_string_pattern  // we want to match certain patterns on the fly
            [ log_interesting_strings ], // and pass them to our logger
     noise_skipper             // but we skip all noise
 );

    在这里，语义动作是解析器功能的核心。它有效，因为在具有语义动作的节点级别不涉及回溯。

  3. 语义行为是精神业力中语义行为的镜像，通常与气相比，它们造成的问题更少；因此，即使只是为了接口/API 的一致性，语义操作也是“一件好事”，并从整体上增强了 Boost Spirit 的可用性。

于 2011-11-24T15:48:38.847 回答