如果我尝试以下代码：
call/wait/output {webrequest http://google.com login password} content
REBOL抱怨错误。相反，我必须使用以下内容：
content: ""
call/wait/output {webrequest http://google.com login password} content
为什么？
更新：我觉得答案很简单......
答案 0 :(得分：4)
“为什么？”是一个棘手的问题！我会试着给出理由......
当从应该收集数据的函数传回一个值并将其移回时，有两个基本选项（在大多数语言中）。
一种是将其用作return。 （在像Rebol和Ruby这样的语言中，隐式返回是代码块中最后一个语句的计算结果。）另一种回传数据的方法是将其戳入一个参数，调用者已经通过“引用”或“通过”指针”。
call的当前设计是它返回进程的退出代码。但是，让我们想象一个替代的宇宙，call的{{1}}的细化改变了返回值，它可能看起来像这样：
/output设计选择不是为了做到这一点。 >> call {echo "test"}
== 0
>> call/output {echo "test"}
== [0 "test"] ; in an alternate universe...
始终返回简单的退出代码。相反，如果您关心调用的call，则通过引用传递参数... Rebol将在其中写入控制台结果。
它非常灵活，因为Rebol允许你（例如）传入一个参数，这是一个打开的文件来写结果...而不是让你存储一个可能非常大的函数返回然后写出来。 /output是应该写入文件还是将结果放在字符串中，而是由“by reference”参数的数据类型提示。
简而言之，这是该语言的设计决定。 Rebol并没有假设输出应该去哪里，而是“嗅探”参数类型并做适当的事情。如果您尚未为call建立数据类型......则无法正常工作。再次，如果我们考虑“替代宇宙”，content的可能有不同的改进：
call然后它不必担心先前是否声明call/outputstring {echo "test"} content
，调用会假设它应该将内容转换为字符串。如果您正在写一个文件，它可以为您创建...就像这样：
content但是，这不会让您写入已存在文件的任意位置或现有字符串中的位置。简单地说，要求call/outputfile {echo "test"} %/myfile.txt content
先前已声明为此。但正如您所注意到的，它需要更多的代码。如果您愿意，您可以将声明内联：
content答案 1 :(得分：2)
很简单。如果在CALL上执行HELP，您将看到/ OUTPUT选项需要以下类型之一的参数：string！，port！，file！，url！或者没有！如果你只是在没有定义内容的情况下传递内容单词，那么你就没有通过了！与参数预期类型不匹配的值，因此会生成错误。