欢迎大家用顶级模型贡献 pcc

python 写编译器前端
想法是挺牛逼的，但是怎么听上去有点不对劲呢。。。

还有后段。

还要去 libc

@jiamo #2 那听上去就更不对劲了呀哥 😂

自己慢慢打磨吧，现在光看下来用途不是很明确

我需要 golang syntax-like 的 rust 代码转换器。

@MindMindMax

我个人有一个项目 复刻并实现了属性文法。 你如果有足够的 token 可以自实现 https://ittybittycomputers.com/
再实现机械翻译。

但 token 足够，ai 理解直接写也行了。

@MindMindMax

类似这种

仓库能做，前提是把「能编译能跑、行为与原程序一致」当验收，而不是「输出人手写那样的 Rust 」。现成资产：

┌────────────────────────────┬─────────┬───────────────────────────────────┐
│ 资产 │ 规模 │ 状态 │
├────────────────────────────┼─────────┼───────────────────────────────────┤
│ t2_emit::emit_rust │ 909 行 │ 已有测试用 rustc 编译并比对退出码 │
├────────────────────────────┼─────────┼───────────────────────────────────┤
│ grammars/c_to_t2.tag │ 155 行 │ 最完整的 X→T2 模板 │
├────────────────────────────┼─────────┼───────────────────────────────────┤
│ grammars/go_to_python.tag │ 42 行 │ 只认一个函数，仅作起点 │
├────────────────────────────┼─────────┼───────────────────────────────────┤
│ grammars/cpp_to_python.tag │ 2676 行 │ 证明 TAG 能覆盖真实语料 │
└────────────────────────────┴─────────┴───────────────────────────────────┘

语法层完全不是问题。Go 只有二十几个关键字，没有预处理器、模板、重载，比我们已经拿下的 C++ 简单得多。差分验收的脚手架上周刚为 js2python 建好，go run 对 cargo run 比 stdout 可以照抄同一套。

真正的墙是语义，不是语法，这决定整个项目的形状：

- 所有权。Go 有 GC ，Rust 没有。确定性翻译的可行做法是把共享值统一装进 Rc<RefCell<T>>，配一个 go_shim crate 提供 GoSlice 、GoMap 、chan 。产物能编译能跑，但不是 idiomatic Rust 。想输出手写风格的借用和生命周期，需要逃逸分析加借用推断，那是研究课题。
- interface 转 trait 。Go 是结构化隐式实现，Rust 是名义显式 impl 。需要跨文件符号表，先收集所有类型和接口，再为满足的组合生成 impl 块。可做，但现有的按文件驱动器没有这个能力。
- 错误处理是加分项。(T, error) 转 Result<T, E>，if err != nil { return err } 转 ?，这块映射最干净。
- 零散语义差异。零值、nil 、slice 的长度容量、map 迭代顺序、整数溢出在 Go 是环绕而 Rust 在 debug 下会 panic 。这些都靠 shim 兜住。

goroutine 和 channel 可以映射到线程加 mpsc ，但 select 和无缓冲 channel 的语义要额外设计，建议放到最后。

我觉得没有意义，再往后 AI 直接生成汇编语言甚至二进制格式
这些高级语言只是为了方便人理解妥协的产物

和 pypy 的区别是？