Yes. I am following the Scheme tradition of representing immediate values as tagged pointers. And (ref i31) is the obvious choice when using WebAssembly.
I am happy you and the team added GC to WebAssembly.
I wouldn't say compiling full Racket to WebAssembly is impossible.
But I think the consensus is that one can't add a WebAssembly backend to the compiler in the same manner as the x86 and arm backends. These backends manipulate the stack in ways WebAssembly prohibits.
This forces an Racket implementation to make continuations explicit.
And that will most likely mean a WebAssembly backend will be slower than the native backends.
Racket is a huge language, so be patient wrt features.
To keep motivation high I decided to implement a subset that
can be used to built practical applications - and then extend
the supported features from there. Hopefully, this strategy
will also lead to some early adopters that can help me
prioritize which features to add.
Some features are simply "more of the same".
In this category falls more types of hash tables.
Supporting bignums are also a matter of just doing it.
Other features require more work. I have already done
some work on implementing modules in terms of linklets.
When linklets/modules work, we can reuse the existing
implementation of regular expressions.
Adding continuation marks and delimited continuations
require adding a CPS-pass. This is certainly doable.
Postponing it has been great though. Having a direct style
compiler means the generated code follows the structure
in the input source code. And that makes debugging easier.
Now that bugs have become rarer, it makes sense to look at CPS.
The code generator is inspired by "Destination-driven Code Generation"
by Dybvig, Hieb and Butler. There are some differences however. The code
generator in the paper generates "flat" code (assembler) whereas I
generate nested Web Assembly instructions.
This approach generates reasonable code without having to implement
a register allocator. Also, I believe I saw a Wasm to Wasm compiler
that improved register allocation (maybe it was a switch for wasm-tools?).
If (when?) WebRacket becomes a success, we can always switch out individual passes.
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.
The Parties will contribute toward the further development of peaceful and friendly international relations by strengthening their free institutions, by bringing about a better understanding of the principles upon which these institutions are founded, and by promoting conditions of stability and well-being. They will seek to eliminate conflict in their international economic policies and will encourage economic collaboration between any or all of them.
>> Can Idris 2 compile itself?
> Yes, Idris 2 is implemented in Idris 2. By default, it targets Chez Scheme,
> so you can bootstrap from the generated Scheme code, as described in Section
> Getting Started.
in this case the generated scheme code is just a strange form of executable file that happens to need ChezScheme to be executed.
i.e. an ELF64 idris2 linux binary vs. an idris2.scm file that needs ChezScheme to come alive.
as for Idris2 implemented in Idris2: well, yes, that's true for the current version of Idris2. but the first version of Idris2 was written in Idris1. and the first version of Idris1 was written in Haskell.
Typically "mock-up", like "wireframe", refers to a model of the user interface appearance, perhaps made with Figma or Photoshop, but I think noosphr is talking about a prototype of the functionality.
Details on the representation.
https://github.com/soegaard/webracket/blob/main/compiler.rkt...
I am more or less only using the linear memory for the JavaScript FFI. FASL-encoded values are passed back and forth to JavaScript.
reply