haskell - 如果 JVM 语言编译过程有一个像 Haskell 一样的 STG 阶段，会有什么变化？

Question

我有一个 friend 说:

For me the most interesting thing about Haskell is not the language and the types. It is the Spineless Tagless Graph Machine behind it.

因为 Haskell 人一直在谈论类型，所以这句话引起了我的注意。现在我们可以看看Haskell的编译过程like this :

1. 解析
2. 类型检查
3. 脱糖 + 一些小 Action
4. 翻译成核心
5. 最大份额的优化
6. 翻译成 STG 语言
7. STG 语言到 C–
8. C– 汇编或 llvm

我们可以简化为:

1. .. 前端的东西..
2. 将 IL 翻译成 STG 语言
3. 将STG语言编译成C/ASM/LLVM/Javascript

即 - 在将 Haskell 编译为 LLVM/C 等之前，Haskell 被编译成一种中间“图形语言”，并且在那里进行了各种优化。

这与看起来像这样的潜在 JVM 语言编译过程形成对比:

1. 在类中将 JVM 语言代码转换为 Java 字节码。
2. 在 Java 虚拟机上运行字节码。

假设可以在 Java 编译过程中添加中间 STG 编译​​步骤，我想知道此更改会产生什么影响？编译后的代码会发生什么变化？

(我知道你需要一种纯函数式语言来充分利用无骨无标签的图形机，所以如果它有助于回答这个问题，假设我们正在编译 Frege [Haskell for the JVM].)

我的问题是:如果 JVM 语言编译过程有一个像 Haskell 一样的 STG 阶段，会有什么变化？

Answer 1

您需要澄清您指的是 Java 语言还是在 JVM 上运行的某种语言。

我对 Java 这种语言的了解仅限于阅读规范，我对您所说的 Haskell IR 一无所知。但是，根据规范，Java 是一种动态语言，执行任何使用每个结束类文件之外的任何信息的 AOT xform 都是非法的。

当然，不使用这些功能的项目可能会违反这些规则。