Luke Boswell schrieb:
But if we refactored that around the tooling capability it would be a much simpler, way less fragile, and we can extend it with more capability easily.
This sounds super interesting, maybe we can move this into a new thread. As someone without any compiler development or even low level experience, it is quite hard to wrap my head around, how the playground is currently implemented and how the internal representations are getting extracted from the compiler. Do you have some pointers on where to start diving into the code?
A message was moved here from #show and tell > Feedback Roc Code Example by Luke Boswell.
So for the roc playground... its all in here
https://github.com/roc-lang/roc/tree/main/src/playground_wasm
That main.zig is built into the playground.wasm (or whatever it's called) by the roc nightlies in CI -- and then it's just HTML, CSS, JS etc to support that in https://github.com/roc-lang/roc-playground
Thanks, I’ll have a look at it and play around with it a bit. Did i get this right, that it is currently not using the roc tooling you talked about?
Yeah roc tooling is kind of on the horizon and not a priority right now. There's still some design questions there to resolve.
The playground currently reaches into the compiler internals ... it doesn't have a clean high level API its using.
Unlike glue or the cli for example which use a high level coordinator pipeline and I think a common API.
Long term architecture all of the tools (and potentially other applications that want to embed the compiler) would interface through a common shared API ... so the roc cli, snapshot tool (golden tests), playground wasm, echo wasm, other test infra etc.
So the way Roc's repo is structured is that everything in src/ is an independent module or a standalone binary
The build coordination is driven by Zig in build.zig and you can see the module dependencies in https://github.com/roc-lang/roc/tree/main/src/build
Last updated: Jul 23 2026 at 13:15 UTC