Comment by gcr
15 hours ago
Is there any shared lineage between this and Whalesong, a previous Racket->JS compiler?
Of course both projects have the same maintainer if I recall, Jens Axel Søgaard is a rockstar :)
15 hours ago
Is there any shared lineage between this and Whalesong, a previous Racket->JS compiler?
Of course both projects have the same maintainer if I recall, Jens Axel Søgaard is a rockstar :)
Jens Axel Søgaard is cool and involved in many things. We collaborated on SICP support.
Original developer of Whalesong was Danny Yoo. https://www.hashcollision.org/whalesong/
There was also this: https://docs.racket-lang.org/racketscript/
Dave Herman worked on various JS-related libraries for Racket (or PLT Scheme) before he was involved with Rust.
ah that's right! apologies
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?
> 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.
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...