定義Ast節點的枚舉

[HsiuCheYu]

請問是否有考慮過定義Ast節點的枚舉?源碼中使用比較多的動態派分，如果改為枚舉應該可以獲得更明確的設計與更好的性能(?

初步的想法是定義類似下面這樣的枚舉(還需要做一些修改):

enum Literal {
    Int(i32),
    Float(f64),
    Bool(bool),
    String(String),
}

enum Expression {
    Literal(Literal),
    Array(Vec<Expression>),
    FunctionCall(String, Vec<Expression>),
}

enum Statement {
    Let(String, Expression),
    Expression(Expression),
    If(Expression, Box<Statement>, Option<Box<Statement>>),
    While(Expression, Box<Statement>),
}

範例:
let a = 10: Statement::Let(a, Expression::Literal(Literal::Int(10)))

不過這樣的定義會牽扯到很多的代碼，如果您願意，我很樂意協助!

[HsiuCheYu]

(順帶一題，我是B站來的(你超厲害)，不過我沒有QQ，qq😭)

[LKBaka]

（哇还有台湾/香港/澳门人）
实际上我不止一次想过这个方案 以及我确认了这个方案是可行的 最近我写了个仿照RustAnt的Evaluator小Demo (就是你所提的枚举方式 包括对象系统也是枚举) 由于换这个方案我肯定需要一个理由，并且我是从GC语言转到Rust的，根据AI我了解到了以下内容：

1. 枚举的大小实际上根据最大的枚举变体决定
2. 我本人使用的储存数字的类型是 BigDecimal 如果该类型过大可能会导致适得其反

对了你可以说下你的名字是啥吗 我去看一眼
print(":)")

[HsiuCheYu]

1. 枚举确实是由最大的变体决定的，所以如果其中一个变体特别大确实会导致整个枚举被拖累，这时候通常就可以用Box来把变体改到堆上存储。
2. 用BigDecimal是因为要处理小数与整数，以及确保精确度吗?如果允许精确度降低，改为原生，或者手搓型别应该也是不错的选择(后者应该更有意义)，精确度的部分可能可以考虑把他作为标准库，但不放在编译器(?

但我刚刚测了一下，动态派分的性能居然优于枚举，或者就算枚举快一点，应该也没有快多少w。如果真的要找理由的话，枚举可以提供更清晰的介面还有模式匹配(在compiler中可以直接比对而不需要用type_id)，但这更多应该取决于习惯。

倘若希望先使用动态派分，在我看来似乎是完全合理的选择，我很乐意协助其他部分!

我是台湾的~，如果你是问B站的帐号，应该是"YuWhisper0825"(我没发过任何东西www)，我还发现我忘了转简体，非常抱歉(跪

[LKBaka]

duck不必 反正大家看得懂就行
高精度一开始就是计划的一部分 所以大概率不会取消
顺带一提我利用 enum_dispatch 重构了整个对象系统 速度能快一点 后面有时间可能会给 AST 也整上
想问一下你多大 (●'◡'●)

[LKBaka]

我是台湾的~，如果你是问B站的帐号，应该是"YuWhisper0825"(我没发过任何东西www)，我还发现我忘了转简体，非常抱歉(跪

我好像在b站上找不到 YuWhisper0825 这个号
我只看见了 yuwhisper 和 YuWhisper_L 这两个号 ovo

[HsiuCheYu]

(我先把一些簡單的問題處理一下，然後發一些PR~)

[LKBaka]

thanks!

[LKBaka]

卧槽卧槽兄弟 我把对象系统利用 enum_dispatch 改成了枚举形式运行fib性能提升 50%！

[LKBaka]

卧槽卧槽我现在fib35只需要15秒了