chicken_esolang

Chicken esolang 的解释器，使用 Rust 构建。如以下内容所示，原始解释器的网页存档对于理解某些实现细节至关重要。

命令行界面使用方法

cargo run -- -f filename [--debug] [--backwards_compatible] [-i optional_input] 

库使用方法

use chicken_esolang::Chicken;

let code = String("chicken");
let input = "";
let debug = false;
let backwards_compatible = false;

let mut chicken = Chicken::new(code, input, debug, backwards_compatible);
chicken.run()

JavaScript 解释器或：如何停止担心并学习鸡鸡鸡

tl;dr 99 个香蕉和 DeadFish 程序需要 --backwards_compatible 标志才能像通过原始解释器运行时那样工作。

对于这样的 esolang，抱怨其复杂的设计似乎很愚蠢——这基本上就是它的目的。然而，了解示例程序在正常运行时对原始解释器所写的 JavaScript 中的怪癖有多么依赖是很重要的。理解原始解释器几乎让我发疯，但这是调试看似无法解释的行为所必需的。请参阅 js_interpreter/demystified.js.txt 文件以获取分析。

Rust 的美在于它通过严格的类型（以及其他规则和保证）迫使开发者面对可能不规律的程序行为。本着这种精神，如果你想用鸡编写程序——明确地说，你不应该这样做，但如果你坚持这样做——这个解释器默认情况下会在原始解释器只会做些奇怪的事情的情况下抛出错误。向后兼容模式是为了在运行旧示例时模拟原始解释器的行为而专门设计的。

以下是原始解释器的反直觉行为以及我选择如何处理它们。一般来说，我只在示例程序依赖于它时才实现了特定的 JS 行为。

比较

99只鸡程序的第34条指令将比较0与从用户输入寄存器加载的值。程序依赖于这一点在某些时候为真，以便跳转到末尾并构建最终的no chickens（对于某些输入）。理智的编程语言在比较0和空字符串时会返回false，但不是JavaScript！因此，当backwards_compatibility启用时，比较模仿了JavaScript松散相等运算符的行为，并且'' == 0被评估为truthy。

原始解释器在比较时返回true和false，当它们被拼接时会被转换为字符串。Deadfish依赖于这种行为来从false中非法地检索字母s，因此，在向后兼容模式下，我们返回"false".to_string()，并硬编码空字符串比较的真值。

ADD

JavaScript中的加法运算符也用作字符串连接，自动将整数转换为字符串。我选择普遍模拟这一点，因为程序的架构依赖于最终输出存储在单个堆栈令牌中。

理论上，如果NaN和undefined在加法操作的任一边，JavaScript也会将它们转换为字符串。请参阅下文的SUB和LOAD条目，了解这些值何时成为问题以及我是如何处理的。

SUB

如果你给99只鸡一个字符串作为输入，它将返回以下模式：OriginalInputString chickens
1 chicken
no chickens
，即OriginalInputString chickens\n1 chicken\nno chickens\n。发生的事情是这样的：程序将在两次尝试中尝试减少输入，然后根据结果进行跳转（跳转是指令36和59）。在JS中，字符串减去数字等于NaN，这是假的。因此，两次SUB的结果都未能通过向前跳转的条件，该跳转本应考虑输入为1的情况，以及向后跳转的该情况，该跳转旨在创建一个循环，直到计数减少到1。

为了在向后兼容模式下复制此操作，我为SUB编写了一个特殊版本，当操作数不匹配时，它返回Token::Chars("NaN".to_string())。然后COMPARE会检查"NaN"作为特殊案例。