How are libraries going to work that depend on things provided by platforms? Say a library for file IO. You wouldn't want to reimplement it for every platform but there's also no standard interface you can rely on. Afaiu you actually have to import a platform into the lib to use IO primitives right?
Closely related to this, how do platforms compose? In a decently sized application you'll want many things like e.g. file IO, graphics, maybe an entity component system and more for a game. Does this always have to be provided as a monolith with the composition happening on the rust/zig/c side?
Platforms do not compose.
They require libraries in the host language to compose
Does the interface feature allow to require things? That could be a way to write libs against an api and have the application provide the required api based on its platform
As for a library that depends on a platform. It depends. Generally speaking there are two main options:
Honestly neither of these is necessarily optimal. I expect some sort of change as this becomes more common
I guess there is a third option: bundle the library with the platform.
there are potentially more options in this space with the interpreted effects design, but that's still WIP
I'll write up a design doc for it at some point, but ideas are still percolating plus we don't have a proof of concept platform using it yet - although I'm planning to get back to that next week now that Advent of Code is over!
I'm keen to explore this design space using roc-tui if that would help; I would love to share code for effects with cli if possible. I've wondered if it might be possible to have roc glue
support interfaces/packages, with the idea to write a host language library which can be shared.
In a decently sized application you'll want many things like e.g. file IO, graphics, maybe an entity component system and more for a game
From previous discussion, I understand the intent is for platforms to naturally evolve around use-cases; and not necessarily general purpose. For example there might be a number of popular game dev platforms evolve which would provide effects and functionality specific to games. These platforms might optimise for a game loop etc.
Related to this concept is that when you have a more niche use-case then you are encouraged to fork one of these platforms and add the functionality you need. It may be something that many people also need, and then be something that could feedback into the evolution of the platform. Note that with roc glue
it should be easy to change the API if needed and re-generate any glue code.
yeah I think the next step regardless is to get effect interpreters working. From there I think we have sufficient primitives to try out some interesting ideas, but they're all predicated on that design actually working in practice, which hasn't been demonstrated yet :big_smile:
any updates here? it feels like a realistic need, but was it asked for to that moment?
right now, platforms are small, but I imagine it's possible a platform provides bare minimum api, and there are multiple platform-dependent roc modules that implement different frontends.
upd: looks like it's exactly what module params for!
Last updated: Jul 06 2025 at 12:14 UTC