Would anyone like to review or comment on this PR which adds a web REPL for Roc https://github.com/roc-lang/roc/pull/10645
To test it locally;
zig build build-repl-wasm
python3 -m http.server 8000 --directory zig-out/lib/repl
Screencast from 2026-08-07 07-28-05.webm
I was thinking about the migration for the Roc website for the new compiler when I noticed we didn't have a REPL -- but we did with the old compiler.
The styling is just plain, I figure the CSS for the website will take over when someone integrates it.
Wasn’t there a repl already in https://roc-lang.github.io/roc-playground/?
Somehow looks confusing to me to have the same things in multiple places but with different design / behavior
Theres also a cli repl, so now we will have three :sweat_smile:
The playground does a lot more than just repl things... most of which we dont need in a minimal web repl. Like features to see all the intermediate IRs etc
But wouldn't it be more efficient to concentrate on one web based one and if you need to embed it simply strip out the unwanted features via some url params and do e.g. an iframe embed?
I mean what's in the end the purpose for:
![]()
So should then this be stripped out of the playground and the playground just having the editor?
Can just say that I personally would be confused if I go to the different roc pages, see different repls and have different behaviour in these (atleast in case of writing and representation, don't know about functionality itself right now)
It the same execution engine under the hood, just the new one I've built has more features so it can do things like autocompletion in the browser, or importing modules, nicer diagnostics etc. It's also more portable as it's just a simple JSON API crossing the WASM boundary, so easy for people to rip off the roc website and run anywhere.
I haven't looked at or thought about the playground in a very long time.. it's just out of scope for what I was thinking. I didn't think it was suitable for the website, but I didn't double check I just launched into researching the requirements for a nice web repl.
Yeah, but why not doing this in the playground? Or is the plan the scrap that playground thing?
The representation of the one in the video above I find cleaner, don't get me wrong. It's just that instead of having one good option and improving on it, it feels like we're creating more options and somehow they then get stale and not improved and then the next option comes (which might be the way to go with LLM stuff, but it feels like it's neglecting the playground, so if that's the case at one point the playground should eventually be deprecated if that's not what users should use, but other new things)
But maybe my thinking is also wrong here. Thought the plan was to have the playground on the official page as well (similar to e.g. the typescript page) where such functionalities would make sense there as well :sweat_smile: anyways cool progress
I'm trying to get the website polished up in preparation for a 0.1 announcement sometime soon. We were discussing the Exercism updates the other day and I noticed things missing or old, like the current REPL on the website is the old compiler.
I'm trying to push along the critical path to help unblock swapping over to the new compiler completely. So I'm trying to remove anything still using the old one... there hasn't been a discussion or decision or anything like that I'm just trying to get prepared ahead of things so it's not a rush later. There are still people using the old compiler in production.
I personally don't use the playground much anymore, but if others find it useful then I don't see why we would want to remove it. There are many features that would be great to add in there -- like being able to inspect all the later compiler stages down to LIR and visibility over the various optimizations like TRMC or ARC etc. It could be a really cool performance oracle or more generally for understanding what is "inside" a bit of roc code. The godbolt of the Roc world, so you can trace the transformations from source code down to machine code...
I have been focusing my time elsewhere but I still think the playground is a great place if anyone wants to contribute or build roc tools without doing the open heart surgery thing in the core compiler.
Yeah, get that. As said my interpretation comes from the assumption that the plan was to use the playground in a similar way as typescript, so as a quick way to play around and iterate without installing anything locally. That is a different focus then really needing to go down to source to machine code.
![]()
Another example is I assume Scala:
![]()
So basically my assumption was to use it to reference and show samples, but also allow quick iterations / playing around / sharing samples via it.
In that case if the new repl and the playground would be part of the page it might be confusing given the different behaviour. If for now it's only the repl, and the playground stays unmentioned and unreferenced this anyways likely doesn't matter, as the playground would hardly be found by somebody just going in fresh into the page to take a first look at the language.
Ah I see... like the Elm try https://elm-lang.org/try experience is where I've seen that before. That would be good too, now we have the echo platform (and a wasm build) that would be very achievable to do on the website.
Maybe it's just me, but the first time I tried Roc's REPL, I quickly wondered what I could actually do, other than pure functions. When I realized that there were no effects, I was a bit disappointed. Perhaps the "Try Roc" REPL could let the user pick a simple platform, such as a "Turtle" platform that lets you move a turtle around in a canvas, or a "Microservice" platform that lets you define a (mock) micro service, or a "Swarm" platform that lets you code the behavior of a little Roc bird, and the platform runs hundreds of them.
This would make it more fun and also illustrate the power of the platform concept.
To me something to print to the console / logs would already suffice, given with that you could in theory already do e.g. Advent of Code in there (though you'd likely need to fumble around a bit with getting the input file inline).
Though I mean through usage it would need to be improved into either direction, e.g.:
![]()
Ignoring that this would anyways be incorrect, likely isn't the best message to give the fresh users, as it doesn't indicate what's possible or not, doesn't help to guide into the correct direction (though playground repl sample, might be different in Lukes repl).
Ok so the REPL I shared above has a "generic" effect interface, so the caller (in this case our demo web app sets up two effects, console.log and a toast) can inject some effects the app can call.
It's limited in that it currently just keeps a record of the effect and then returns a list of the effects to run back to the caller. So they aren't real effects like a normal platform.
And because of this they are one way (app -> host) only
So we could totally add a simple turtle platform, or drawing SVGs, or things like that
Turtle platform sounds good :)
I would keep the editing experience pretty simple, it's tempting to creep towards an IDE over time.
a turtle platform reminds of Jeroo: https://www.jeroo.org/
this was how i learned to code in high school! fond memories of making a kangaroo jump around haha
Luke can bless the kangaroo :flag_australia: :p
Last updated: Aug 12 2026 at 12:35 UTC