为什么 ISO/IEC 13211-1:1995 的技术勘误 2 从 "token" 规则中省略了 "bar"?
Why did Technical Corrigendum 2 to ISO/IEC 13211-1:1995 omit "bar" from the "token" rule?
Cor.2 说(仅)关于第 6.4 条的以下内容:
6.4 Tokens
Add as the last syntax rule:
bar (* 6.4 *)
= [ layout text sequence (* 6.4.1 *) ] ,
bar token (* 6.4.8 *) ;
当然是对6.4的另一种修改,即在token (* 6.4 *)
的定义中增加bar (* 6.4 *)
,在ISO/IEC13211-1中如下: 1995:
token (* 6.4 *)
= name (* 6.4 *)
| variable (* 6.4 *)
| integer (* 6.4 *)
| float number (* 6.4 *)
| double quoted list (* 6.4 *)
| open (* 6.4 *)
| open ct (* 6.4 *)
| close (* 6.4 *)
| open list (* 6.4 *)
| close list (* 6.4 *)
| open curly (* 6.4 *)
| close curly (* 6.4 *)
| ht sep (* 6.4 *)
| comma (* 6.4 *)
;
这是 Cor.2 的一个小遗漏还是我误解了?
这是使 ISO/IEC13211-1:1995 更加一致的绝佳发现!是的,对于 Cor.2:2012,规则 token (* 6.4 *)
应该通过进一步的选择
进行扩展
| bar (* 6.4 *)
另一方面,我没有看到遗漏或扩展的任何直接后果。但我同意这肯定会使标准更易于理解。
这里有论点,为什么即使没有进一步添加,当前的法典也很好:
1。非终端栏已作为标记包含在内
唯一使用(* 6.4 *)
的地方是术语输入内置谓词的子句8.14.1 read_term/3、read_term/2、read/1, read/2。在那里,8.14.1.1 g) 读取:
g) Attempts to parse C_Seq
as a sequence of tokens
(6.4),
...
现在"a sequence of tokens (6.4)"不是对特定非终结符号的精确引用。在 6.4 下有各种非终端,特别是最近添加的 bar (* 6.4 *)
。因此,可以引用在 (6.4) 中定义的任何标记或标记序列。而且,定义标记序列的实际非终结符称为 term (* 6.4 *)
,但 "a sequence of tokens (6.4)" 和 "a term (6.4)" 看起来完全不同。所以我看不出有什么好的理由不在 read/1 和 family.
读入的标记中包含 bar
此外,术语句法 (6.3) 始终明确指代条 (6.4)。
在 8.14.1.1 k 中还有另一个参考文献
k) Parses C_Seq
as a read-term (6.4) T.
,
这被理解为一个错误。 WDCor.3 读取 8.14.1.1 k:
k) Parses C_Seq
as a read-term (6.4) (6.2.2) T.
,
粗略地说,read/1
分两个阶段读取一个术语:在第一阶段,字符被读入并立即被解析为一个标记序列,直到遇到结束标记 (6.4.8)。因此,在拥有一系列已被解析为标记的字符之后,再次执行此操作毫无意义。此外,这不会产生任何具体条款。只有6.2.2中read-term的定义才能确定第k步要获取的termT
。 6.4完全没啥好说的,就是token而已
2。即使 bar 不是标记序列的一部分,也可以读取术语
但即使不接受第一个参数,8.14.1.1 中的过程描述仍然能够在 8.14.1.1 g 中将字符序列 C_seq
解析为标记序列,因为token ht sep (* 6.4 *)
描述了与 bar (* 6.4 *)
完全相同的一组字符序列。这些非终端之间的唯一区别是 ht sep
专门用作列表符号 (6.3.5) 的头尾分隔符,而 bar
用作中缀运算符。总而言之,步骤 g 和 k 现在以不同的方式解析文本 a --> b | c.
:步骤 g 将 " |"
解析为 ht sep
,步骤 k 将其解析为 bar
——前提是有一个拟合运算符像
这样的声明
:- op(1105, xfy, '|').
Cor.2 说(仅)关于第 6.4 条的以下内容:
6.4 Tokens
Add as the last syntax rule:
bar (* 6.4 *) = [ layout text sequence (* 6.4.1 *) ] , bar token (* 6.4.8 *) ;
当然是对6.4的另一种修改,即在token (* 6.4 *)
的定义中增加bar (* 6.4 *)
,在ISO/IEC13211-1中如下: 1995:
token (* 6.4 *) = name (* 6.4 *) | variable (* 6.4 *) | integer (* 6.4 *) | float number (* 6.4 *) | double quoted list (* 6.4 *) | open (* 6.4 *) | open ct (* 6.4 *) | close (* 6.4 *) | open list (* 6.4 *) | close list (* 6.4 *) | open curly (* 6.4 *) | close curly (* 6.4 *) | ht sep (* 6.4 *) | comma (* 6.4 *) ;
这是 Cor.2 的一个小遗漏还是我误解了?
这是使 ISO/IEC13211-1:1995 更加一致的绝佳发现!是的,对于 Cor.2:2012,规则 token (* 6.4 *)
应该通过进一步的选择
| bar (* 6.4 *)
另一方面,我没有看到遗漏或扩展的任何直接后果。但我同意这肯定会使标准更易于理解。
这里有论点,为什么即使没有进一步添加,当前的法典也很好:
1。非终端栏已作为标记包含在内
唯一使用(* 6.4 *)
的地方是术语输入内置谓词的子句8.14.1 read_term/3、read_term/2、read/1, read/2。在那里,8.14.1.1 g) 读取:
g) Attempts to parse
C_Seq
as a sequence of tokens
(6.4),
...
现在"a sequence of tokens (6.4)"不是对特定非终结符号的精确引用。在 6.4 下有各种非终端,特别是最近添加的 bar (* 6.4 *)
。因此,可以引用在 (6.4) 中定义的任何标记或标记序列。而且,定义标记序列的实际非终结符称为 term (* 6.4 *)
,但 "a sequence of tokens (6.4)" 和 "a term (6.4)" 看起来完全不同。所以我看不出有什么好的理由不在 read/1 和 family.
此外,术语句法 (6.3) 始终明确指代条 (6.4)。
在 8.14.1.1 k 中还有另一个参考文献
k) Parses
C_Seq
as a read-term (6.4)T.
,
这被理解为一个错误。 WDCor.3 读取 8.14.1.1 k:
k) Parses
C_Seq
as a read-term(6.4)(6.2.2)T.
,
粗略地说,read/1
分两个阶段读取一个术语:在第一阶段,字符被读入并立即被解析为一个标记序列,直到遇到结束标记 (6.4.8)。因此,在拥有一系列已被解析为标记的字符之后,再次执行此操作毫无意义。此外,这不会产生任何具体条款。只有6.2.2中read-term的定义才能确定第k步要获取的termT
。 6.4完全没啥好说的,就是token而已
2。即使 bar 不是标记序列的一部分,也可以读取术语
但即使不接受第一个参数,8.14.1.1 中的过程描述仍然能够在 8.14.1.1 g 中将字符序列 C_seq
解析为标记序列,因为token ht sep (* 6.4 *)
描述了与 bar (* 6.4 *)
完全相同的一组字符序列。这些非终端之间的唯一区别是 ht sep
专门用作列表符号 (6.3.5) 的头尾分隔符,而 bar
用作中缀运算符。总而言之,步骤 g 和 k 现在以不同的方式解析文本 a --> b | c.
:步骤 g 将 " |"
解析为 ht sep
,步骤 k 将其解析为 bar
——前提是有一个拟合运算符像
:- op(1105, xfy, '|').