2

我有一个 Common Lisp 阅读器宏来解析“或”关系的惰性/延迟声明，使用由管道字符（“|”）分隔的中缀语法以及标准列表括号和关键字文字。考虑 (:a :b|:c) 形式——它表示一个 2 部分元组，其中第一个元素肯定是 :a，第二个元素是 :b 或 :c。例如，可以推断出整个元组的有效形式是 (:a :b) 或 (:a :c)。

我已经有函数封装的逻辑来解构这些元组列表形式在读取宏之后。但是在阅读时，我需要解析像 :a|:b|:c 这样的表单，并用移除的管道对其进行标记，例如 (:lazy-or :a :b :c)。中缀语法的使用纯粹是为了面向读者的形式；中缀形式是短暂的，并在读取阶段立即被丢弃，以支持使用 :lazy-or 标记的等效合法 lisp 形式。

所以我做了一个 read 宏，它几乎可以按我的意愿工作，但目前需要在第一个 or-form 关键字元素之前使用一个额外的管道作为一种阅读器符号（我希望这不是必需的根本），并且它目前无法使用嵌套括号或拼接符号来推断类似的形式作为等效（就像在算术中一样，2+(3*4)是相同的操作顺序，等效形式， as 2+3*4）。

宏（源自“斜线阅读器”：http ://www.lispworks.com/documentation/HyperSpec/Body/f_rd_rd.htm ）：

 (defun pipe-reader (stream char)                                                                   
   (declare (ignore char))                                                                          
   `(:lazy-or .  ,(loop for dir = (read stream t nil t)                       
                   then (progn (read-char stream t nil t)                                           
                               (read stream t nil t))                         
                   collect dir                                                                      
                   while (eql (peek-char nil stream nil nil t) #\|))))                              
(set-macro-character #\| #'pipe-reader)

预期目标是在读取时应用/替换此重写规则： (macroexpand '(:a (:b | :c))) -> (:a (:lazy-or :b :c)) 或者，括号中未包含的变体形式相同（一种默认的操作顺序；空格不会产生影响）： (macroexpand '(:a :b|:c)) -> (:a (: lazy-or :b :c)) (macroexpand '(:a :b | :c)) -> (:a (:lazy-or :b :c)) 嵌套表单应该直观地递归渲染： (macroexpand ' (:a (:b | (:c | :d)))) -> (:a (:lazy-or :b (:lazy-or :c :d)))

请注意，在基本形式的预期重写规则中 -- (macroexpand '(:a (:b | :c))) -> (:a (:lazy-or :b :c)) -- :a 不会以 or 形式加入，因为它没有中缀管道运算符来加入它；它以一种元组的形式与 or-form 的结果一起存在。如前所述，在进一步评估惰性形式时，可以想象，元组可能会产生 (:a :b) 或 (:a :c) - 以上暗示两者都是稍后解构的有效形式。

我非常接近。

问题是我不能完全理解，只有以下（使用上面的宏）： (macroexpand '(:a |:b|:c )) -> (:A (:LAZY-OR :B :C) ) (macroexpand '(:a :b |:d|:e|:f|:g)) -> (:A :B '(:LAZY-OR :D :E :F :G)) 它实际上做的最多我打算这样做，它是一个功能性的基本解决方案：稍微修改执行规则以允许在读取时在中缀或表单的开头有一个额外的管道，而无需将表单连接到该管道的左侧，因此它可以使 :b 到 :c （第一种形式）或 :d 到 :g （第二种形式）成为 :lazy-or 形式列出的有效案例，并使该内部列表本身成为外部列表的成员/元组与非变量值 :a 和 :b 并排。它接近我想要的： (macroexpand '(:a :b :d|:e|:f|:g)) -> 应该，不 -> (:A :B '(:LAZY-OR :D :E :F :

有 3 个错误，按重要性排序：

  1. 需要额外的“前缀”管道

    额外的开口管道，在每个被读取的或形式开始时，我不想这样做。我想切割该管道以保持清洁和我自己的可读性偏好，并且仅在该读取宏的完全中缀位置使用该管道。

  2. 递归解析时向嵌套表单添加了额外的括号

    它为嵌套表单添加了额外的括号，尽管它可以很好地递归处理嵌套表单。

  3. 空白不被任意接受

    它不接受管道之间的空格。我尝试使用 read-preserving-whitespace 而不是 read，在这里无济于事。它应该接受管道和关键字形式之间的空格，就好像它们不存在一样，因为形式:a|:b和:a | :b是等价的。

read 宏主要封装了工作逻辑，擅长递归和嵌套形式： (macroexpand '(:a |(|:b|:c)|(|:e|:f))) -> yield -> (:A (:LAZY-OR ((:LAZY-OR :B :C)) ((:LAZY-OR :E :F))))
;(几乎完美，完全按照预期递归扩展，唯一的问题除了需要开头的管道之外的形式是在最终的 :lazy-or 形式周围生成的双括号）。这样就可以从这种形式产生相同的结果（当前是“不平衡”读取括号错误）： (macroexpand '(:a (:b | :c) | (:e | :f))) -> 应该，确实不屈服 -> (:A (:LAZY-OR (:LAZY-OR :B :C) (:LAZY-OR :E :F)))

除了 read 宏添加的额外括号，以及它无法在中缀形式中允许间距之外，真正关键的错误是无法在不包括第一个非中缀管道的情况下将 or-form 编写为中缀管道形式（附带前缀）。我真的碰到了一堵砖墙，试图匹配流，而不需要使用第一个管道字符作为读取解析器的一种标志。也许对“peek”函数之一的额外调用或两次调用会给我一个更专业的匹配形式，但我无法弄清楚如何解析它。

我考虑围绕现有的综合解决方案构建它，例如 NKF（“definfix”宏，https: //www.cliki.net/infix ）和 CMU 中缀（https://github.com/rigetti/cmu-infix/blob /master/src/cmu-infix.lisp），但由于它们是更通用和更大的代码库，我认为我不需要为更多类型的表单/运算符重用中缀逻辑，仅此一个。从我在一个相当小的宏上的接近程度来看，我肯定更喜欢用一个小而简洁的解决方案来解决它，只要它仍然是递归的并且不容易出错。

任何关于为此目的更有效地使用读取宏的观点都将不胜感激。

4

1 回答 1

5

我会尝试不同的方法并使用不同的字符作为替代列表，例如[a|b]，这样您就不需要前缀栏。

例如：

;; a bar is now the symbol 'or
(set-macro-character #\| (constantly 'or))

;; read a list of forms for alternative forms
(set-macro-character #\[
                     (lambda (stream char)
                       (declare (ignore char))
                       `(lazy-or-parse
                         ,@(read-delimited-list #\] stream t))))

;; this one is required too so that e.g. `a]` is not read as a single symbol.
(set-macro-character #\]
                     (lambda (stream char)
                       (declare (ignore char))
                       (error "Unmatched closing bracket")))

有了上面的定义，下面的表格：

[:a|:b|:c]

读作：

(LAZY-OR-PARSE :A OR :B OR :C)

预计这lazy-or-parse是一个宏。它的作用是解释一个令牌列表，就像一个普通的解析器；您应该能够将它们分组为表达式（例如，具有定义的关联性/优先级的 Pratt 解析器）。

或者，您仍然可以在阅读器宏中进行解析，但我个人更喜欢在这个阶段做尽可能少的工作。

注意。对于我使用的测试，您需要调整 Emacs 以使其理解此语法read-from-string：

(read-from-string "[a b (c|d)]")
(LAZY-OR-PARSE A B (C OR D))
11

我看了一点，这是我在语法表中更改的内容（这是 emacs-lisp 代码）：

(modify-syntax-entry ?\[ "(]" lisp-mode-syntax-table)
(modify-syntax-entry ?\] ")[" lisp-mode-syntax-table)
(modify-syntax-entry ?| "_" lisp-mode-syntax-table)

通过这些修改，编辑器似乎可以识别语法，我什至可以这样写，将光标放在右括号后，评估 last-sexp 并正确找到表达式的开头：

'[ a | (c | d)]
=> (LAZY-OR-PARSE A OR (C OR D))
于 2021-02-05T09:40:51.050 回答