parsing - R5RS 方案中未引用的向量

Question

我正在尝试编写一个方案解析器作为练习，但我不确定如何实现向量语法。该规范似乎表明输入向量的方式是'#(1 2 3)，并且这样的向量应该评估为#(1 2 3)。但是，当我在几个 Scheme 实现中进行试验时，#(1 2 3)也被接受为有效输入。这是对规范的普遍实施扩展吗？

Answer 1

根据 R ⁵ RS 规范，必须引用向量：

请注意，这是向量的外部表示，而不是对向量求值的表达式。像列表常量一样，向量常量必须被引用：

'#(0 (2 2 2 2) "Anna") 

一些实现选择允许评估未引用的向量，但任何此类扩展都是非标准的，并且是该特定实现的“特征”。

---

对于它的价值，即将到来的R ⁷ RS 规范明确要求向量进行自我评估：

向量常量是自求值的，所以它们不需要在程序中被引用。

Answer 2

根本不是通用的。例如， Chicken不允许您评估未引用的向量。

#;1> #(1 2 3)

Error: illegal non-atomic object: #(1 2 3)
#;1> '#(1 2 3)
#(1 2 3)

Answer 3

关于标准和实现的有趣的事情。只要不与规范冲突，实现就可以为您提供许多功能。因此，一种实现希望 #(1 2 3) 像自我评估一样被评估，这没关系，因为无论如何这在符合 R5RS 的程序中永远不会发生。在 R5RS 中，运行不符合 R5RS 的程序，例如

(define test "hello")
(string-set! test 0 #\H)

未定义。它可能会失败，不会默默地更改测试或更改测试。R6RS 也是如此，但实现可能会发出错误信号 - 但仍然不必这样做。

AFAIKracket拥有最严格的 R5RS，但即使是它们的实现也有一些额外的东西。例如。它们允许规范中不允许的符号，并且它们在报告环境中定义了符号，以在球拍的模块系统中提升 R5RS。然而，像所有实现一样，当给定一个符合 R5RS 的程序时，几乎没有错误。