[soegaard]

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.

[brabel]

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?

[shakna]

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...

[soegaard]

> 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.