我对eval感到困惑。我查看了schemers.org中eval的规范。它说
程序：(eval expression environment-specifier)
它向我表明environment-specifier是强制性要求。但是，当我使用两个解释器（repl.it和Elk Scheme）测试eval时，它们都在没有environment-specifier的情况下工作。我的问题是：他们都是不符合要求的口译员，还是我在schmers.org读错了文件？
然后..
Elk Scheme评估(eval 5)和(eval (list + 5 6))没有问题，但repl.it上的Scheme解释器无法评估它们。后者将评估(eval `(+ 5 6))罚款而不是前两个表达式。我的问题是：repl.it解释器的行为是否符合？
其他Scheme解释器如何处理前两个表达式？
答案 0 :(得分：2)
计划报告是编写兼容程序时需要遵循的。除此之外，实现本身可以有自己的语法和过程，并且它不会干扰，因为标准的符合程序不会使用它们。并非所有Scheme报告都必须eval，因此您需要找出它应符合哪个报告，以及是否需要按照标准进行切换。例如。 ikarus需要--r6rs-script作为正确运行R6RS程序的开关。我认为Elk是R4RS，因此在该报告中未指定eval，并且BiwaScheme似乎在其源中引用了R6RS，因此它应该采用第二个参数。它的工作原理并不能证明它符合要求，所以你应该在他们的文档中稍微挖掘一下。
此外，在报告中定义为未定义的所有内容您实际上可能会选择某些内容并且仍然根据报告。例如。我已经看到define返回绑定的对象，并且所有!过程都返回它变异的对象，并且根据报告全部，因为任何值都等于报告未定义的值。
此外，报告中的错误实际上要求发出错误信号。由于并非强制要求错误发送给开发人员，以确保他们不会做任何被认为是错误的事情。这些实现实际上可以返回一些非常错误的值，崩溃或者如果它是一个很好的实现它会发出错误信号。其中任何一个对报告都同样好。事实上，这是其中之一：
(define (test) "hello")
(string-set! (test) 0 #\H) ; might signal an error
(test) ; might evaluate to "hello", "Hello"
在大多数Scheme实现中，您不会收到任何错误，并且可能会test返回"Hello"。该报告明确指出这是一个错误，所以我想这意味着你永远不应该为任何Scheme解释器制作这样的程序，因为结果是未定义的。