EnDeRBeaT (Aug 23 2025 at 17:09): EnDeRBeaT (Aug 23 2025 at 17:09):I am trying to use a Num.pow inside a repl in roc playground, but I have several issues.
When I am trying to do Num.pow(1, 2), the repl straight up crashes.
When I try to do import Num, i get LayoutError. Is importing for interpretor not implemented yet?
Anton (Aug 23 2025 at 17:25):When I try to do
import Num, i getLayoutError. Is importing for interpretor not implemented yet?
Builtins like Num are imported by default and never need to be imported explicitly.
When I am trying to do
Num.pow(1, 2), the repl straight up crashes.
I think the new compiler can not yet evaluate all the code in Num.roc yet, so that's probably why it's not available.
EnDeRBeaT (Aug 23 2025 at 17:33):Anton said:
imported by default
cir says ident_not_in_scope (https://roc-lang.github.io/roc-playground/#content=bW9kdWxlIFt4XQp4ID0gTnVtLmFkZCgxLCAyKQ==). It is either a misleading tag, or there is no prelude or something third.
Anton (Aug 23 2025 at 17:37):I checked; Num.roc is not yet included in src/builtins/roc/
Anton (Aug 23 2025 at 17:42):Result.roc is included in there but e.g. is_ok also triggers undefined variable, I think no builtin functions are hooked up yet.
EnDeRBeaT (Aug 23 2025 at 17:42):oh, that is where they are stored, i should check the structure of the project.
How does that actually work? I see num.zig in src/builtins/, as well as many other standard modules. What does it take to include them into prelude? Why are they not in the prelude? Are they any tracking issues for those?
EnDeRBeaT (Aug 23 2025 at 17:46):Also, since we are talking about this, I was wondering on what will be the story for interop between system languages and roc. Considering that the std is implemented in zig via extern functions, will regular folks be able to do the same thing for their own libraries?
Anton (Aug 23 2025 at 17:49):I see
num.ziginsrc/builtins/, as well as many other standard modules. What does it take to include them into prelude?
These are mostly copied from the old compiler (crates/compiler/builtins/bitcode/src/num.zig) and slightly altered. The compiler can not compiler the roc part of Num.roc yet (like in crates/compiler/builtins/roc/Num.roc) so they can't be included yet.
Anton (Aug 23 2025 at 17:51):Are they any tracking issues for those?
No tracking issue yet, we could make hundreds of issues for all planned functionality. We generally communicate here to discuss the next steps that are available for implementation.
Anton (Aug 23 2025 at 17:54):Considering that the std is implemented in zig via extern functions, will regular folks be able to do the same thing for their own libraries?
We don't plan to support other language implementations for std functions. People can write their own variants with other names if they wish, using e.g a platform in their language.
Anton (Aug 23 2025 at 17:56):interop between system languages and roc
Next to platforms, I think we still plan to support compiling roc functions to a library, so you can call them from any language, I think using the C ABI but I'm not 100%.
Anton (Aug 23 2025 at 17:57):Like roc build --lib in the old compiler
EnDeRBeaT (Aug 23 2025 at 18:00):That is not really what I meant. Suppose I want to create a linalg library for Roc. I want it to be quite fast, so instead of using roc, I build it with C/Zig/Fortran, and expose API via C FFI. Will I be able to that in roc at some point?
Brendan Hansknecht (Aug 24 2025 at 16:15):It can be part of a platform and exposed to roc as such, but it can not be a standalone library
Brendan Hansknecht (Aug 24 2025 at 16:16):If we allowed standalone libraries with arbitrary ffi, that would break rocs guarantees around platforms, effects, and io.
EnDeRBeaT (Aug 24 2025 at 17:07):Brendan Hansknecht said:
It can be part of a platform
Considering that you can only have one platform, don't you think that it might be too restrictive? You would need to have a separate ecosystem for platforms, and interop between platforms written in two different languages will become very cumbersome
Brendan Hansknecht (Aug 24 2025 at 19:58):Quite possibly, but breaking the fundamentals safety guarantees of roc sounds significantly worse.
Also, a platform could offer generic ffi primitives if they wanted and a shared wrapper could be written in roc. That at least works for shared libraries.
Oh, and given most nice platform ecosystem have a packaging solution, it does not sound hard to make a library meant to be shared between multiple platforms. A library just to fill in the primitives for roc.
EnDeRBeaT (Aug 24 2025 at 20:26):Brendan Hansknecht said:
most nice platform ecosystem have a packaging solution
the problem is that roc allows a platform to be written in any language (it's even one of the selling points). But interop between two system languages is not pleasant at best..
I am not fully sold on "platform can be used for shared libraries", since that means all of them will be effectful.
I don't really understand how libraries with C FFI (akin to how std lib is implemented) break rocs guarantees? Because the library can do syscalls outside of the platform code? Or there is something else I am missing
Brendan Hansknecht (Aug 24 2025 at 22:43):EnDeRBeaT said:
the problem is that roc allows a platform to be written in any language (it's even one of the selling points). But interop between two system languages is not pleasant at best..
Sure, but most major library tends to have cffi and be integrated in many languages. Blas, lapack, sqlite, etc. it does leave some split in the ecosystem, but nothing abnormal.
I am not fully sold on "platform can be used for shared libraries", since that means all of them will be effectful.
Yes, they have to be effects. Roc can make zero guarantees around the purity of c/zig/rust/etc code.
I don't really understand how libraries with C FFI (akin to how std lib is implemented) break rocs guarantees? Because the library can do syscalls outside of the platform code? Or there is something else I am missing
They aren't akin to the std lib implementation. The std lib is audited by us to respect the rules of roc. It guarantees purity from roc's perspective, uses the correct allocators, and never perform io/effects.
An arbitrary escape hatch in library code would mean:
Roc has strong safety and correctness guarantees. By allowing arbitrary cffi, you lose all those guarantees. Every roc library would need to be much much more carefully audited. They are no longer sandboxed and trustable by default. The worst a roc library can do if written in pure roc is hang, crash, or oom. No other side effects.
EnDeRBeaT (Aug 25 2025 at 04:54):in that case, i wonder what would be the scope of roc standard library? Considering that you are the only people who are allowed to write pure code in performant languages, you'd naturally have to implement a lot of things so that not every function in the world is effectful.
Brendan Hansknecht (Aug 25 2025 at 06:13):Roc's standard library plans to be pretty minimal and mostly datastructures.
Brendan Hansknecht (Aug 25 2025 at 06:14):I would guess that classes of roc applications will be exceptional effectful.
Brendan Hansknecht (Aug 25 2025 at 06:15):For example, a script for a game engine might be nearly all effectful functions just with some pure kernels for algorithm. But most of it would be running effects in the game engine
Brendan Hansknecht (Aug 25 2025 at 06:16):A high performance application that needs advanced linear algebra and potentially GPU support likely would also be very effect heavy. That or just wouldn't be the most suited app to write in roc.
Brendan Hansknecht (Aug 25 2025 at 06:16):Effects are very streamlined in roc, so it isn't a big deal to have a ton of them
Brendan Hansknecht (Aug 25 2025 at 06:17):I would say calling effects in the application is basically is zero cost. Calling effects in libraries that expect to be shared is higher costs, but not a huge deal, just kinda explicit.
Brendan Hansknecht (Aug 25 2025 at 06:19):I do think this tradeoff will shape the more common applications seen in roc.
EnDeRBeaT (Aug 25 2025 at 06:30):Brendan Hansknecht said:
I do think this tradeoff will shape the more common applications seen in roc.
What kind of applications do you think Roc will be suited for? I heard some comments that Roc looks like "DSL over platform" which seems like a good summary.
Anton (Aug 25 2025 at 08:21):What kind of applications do you think Roc will be suited for?
Some things that come to mind: web, enterprise applications, games, scripts
Anton (Aug 25 2025 at 08:21):"DSL over platform" will be one area of applications but that feels a bit narrow as a general description.
Brendan Hansknecht (Aug 26 2025 at 00:13):I think fundamentally it will be suited for a lot of general purpose compute. It may not always have access to the highest performance libraries, but platforms hopeful will package the core of what users might need. On top of that many forms of io can be boiled down to primitives that can be easily shared. For example, a basic socket primitive could be used to build up to tcp, http, and sql queries all in pure roc. So platforms could opt just to give basic primitives like that and allow roc to deal with all layers above that.
Brendan Hansknecht (Aug 26 2025 at 00:15):Fundamentally, most developers are just dealing with getting correctness with good enough perf. They are not working on hyper optimized solutions. Most logic in this category could be written in pure roc.
Brendan Hansknecht (Aug 26 2025 at 00:16):I do think roc has rather large disadvantages for perf heavy number crunching and similar problem spaces that would require relying on complex cffi library.
Brendan Hansknecht (Aug 26 2025 at 00:17):But at any point, a platform could wrap libffi and allow roc do load shared libraries and do generic ffi. That would make it at least as capable as ruby or python in terms of ffi capabilities. Not a great solution, but functional (note: might require some additional compiler support for better experience).
Luke Boswell (Aug 26 2025 at 00:52):I also see this as a major selling point of roc. You still have access to the highest performance possible, but it's wrapped in a very ergonomic API.
Good platforms will bundle everything needed for a particular domain, and it will be worth the effort to optimise the experience using that platform. So not only will performance be better, but I also think various other cross cutting things will be advantaged, like security, portability, reliability, etc ...
Last updated: Sep 09 2025 at 12:16 UTC