hi I can sort of imagine answers to these questions but I'm not sure,
would it work to compile roc code at runtime and load it into the platform?
I get that the application can only have one platform, can the platform run many copies of one or more applications?
how best can I determine the possible functions and values I could use while implementing a platform? right now I would guess I'd copy one of templates or platforms and then guess and check?
thanks you!
would it work to compile roc code at runtime and load it into the platform?
Yes. Though you need roc
accessible as an executable or I guess linked into the platform. You can have roc create a shared library and then load that dynamically at runtime.
can the platform run many copies of one or more applications?
It should be possible but has not be done yet. This likely would require specialized loading and would not fit the standard roc process.
how best can I determine the possible functions and values I could use while implementing a platform?
I'm not sure what this is asking.
I get that the application can only have one platform, can the platform run many copies of one or more applications?
I would think of this as the embedded use-case which we definitely want to support.
Think of something like a big game engine or editor, it might use lot's of different Roc apps for scripting various functionality.
Roc would be a nice friendly high-level language that users can write code it, but still have excellent performance and integration with the underlying engine in a safe/secure way.
Instead of having a heavy boundary interface like a WASM runtime, the engine or editors is just calling roc using plain old functions compiled to (optimized) machine code.
thank you both. I understand the language has changed somewhat over time, is there a platform repo updated to the latest styles that I could learn from?
Hi @Drewry Pope,
basic-cli and basic-webserver are the most up to date, tested and well featured platforms.
Here are some more exotic (also up to date) platform configurations:
https://www.roc-lang.org/examples/ElmWebApp/README.html
https://github.com/niclas-ahden/joy (only tested on linux x64)
https://www.roc-lang.org/examples/GoPlatform/README.html (only works on linux x64)
https://www.roc-lang.org/examples/DotNetPlatform/README.html (only works on linux x64)
thank you!
hi again I have another question, I'm still working through running existing platforms and rebuilding hello world and other simple apps again and again design phase. one thing I want to do, is run other people's roc code in containers on a vps. one day dynamic loading or whatever magic but today I can just compile it and throw it in a container.
I mention this because I'm not so worried about someone escaping roc/container/vm into network as I am about content policy for code creators or guests in their code playground.
what I'm interested in is whether there are any designs around inspecting roc at runtime? not like today, just trying to understand if this makes sense or is totally out of scope so I can plan. I plan to test io to start that is given. maybe I can write my own roc code in the platform package, they would have to run that roc code right? still would be io limited.
I'm pretty sure variable names are erased at compile but would there be any way to "inspect" a roc program maybe specifically during a host io function basically getting the stack frame breakpoint info,
4 ints and a str in global space and values
2 args and their values
function local and it's value
etc
maybe a debug build/literally breakpoints but I was thinking more during release runtime host can audit as needed
anyways I'll try to stick to more immediate concerns for a while and not drop a bunch of random thoughts :sweat_smile:
Richard gave a talk once with a Roc demo where you can approve network calls to specific website on a case by case basis. Can someone provide a link for that, I can't find it. That may be close to what you're talking about @Drewry Pope.
With the new compiler we'll also be making a Roc interpreter, it is likely we'll give it advanced inspection abilities.
For now, if you build your program with roc build main.roc --linker=legacy
you'll get access to better debug info. I also recommend roc build main.roc --emit-llvm-ir
and inspecting the main.ll file that was created, so you can see which function names you can track with gdb or lldb. The .ll file can also help you get a better understanding how a Roc program is translated to a low level IR.
Giving people advanced control over the program's access to files, sending requests to websites and sensitive operations in general is something we'd like to experiment with.
I think this is the talk?
https://youtu.be/cpQwtwVKAfU?si=URrb-iDm9vqFdQBp
Yes, that's the one, thanks @Kiryl Dziamura :)
what I'm interested in is whether there are any designs around inspecting roc at runtime?
One thing that comes to mind, is that Roc doesn't have a runtime ... AFAIK we compile the app down to plain old functions and data. So there isn't really anything Roc would do in this regard.
OTOH the platform has all the control, and calls into Roc passing in various function pointers for IO and things like allocation. So there is nothing stopping a platform author from implementing some cool runtime inspection features.
I'm pretty sure variable names are erased at compile but would there be any way to "inspect" a roc program maybe specifically during a host io function basically getting the stack frame breakpoint info,
You could objdump the static library or object file roc produces.
Also in case you haven't seen it, we have some nice debugging tooling that produces our snapshot files. You can see the syntax and semantic analysis in an s-expression format.
Last updated: Jul 26 2025 at 12:14 UTC