Comment by soegaard
15 hours ago
No, there is nothing in common with Whalesong.
Whalesong used the built-in bytecode compiler and compiled the bytecode to JavaScript. Reusing the bytecode compiler is in principle a good idea - but each time the bytecodes are changed, Whalesong needs to be updated.
And after the move to Chez Scheme as backend, the bytecode compiler is no longer a part of the main compilation path.
JVM languages always target bytecode because it’s much simpler and stable than Java as a language. It almost never changes and when it does it normally won’t break code generation since it’s only adding type system information, for example, as with records.
Is Racket bytecode different?
JVM bytecode is well specified. [0]
Racket is not [1]. It's just the internal representation that the compiler uses. Sort of like marshalling in Python.
[0] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.ht...
[1] https://docs.racket-lang.org/raco/API_for_Making_Bytecode.ht...
> Is Racket bytecode different?
Changes to the bytecode representation were indeed rare also in Racket.
The Whalesong project was written as part of a dissertation - and when people graduate and get jobs, projects are often abandoned.