Leander Behr (Dec 31 2022 at 12:19): Leander Behr (Dec 31 2022 at 12:19):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?
Brendan Hansknecht (Dec 31 2022 at 12:28):Platforms do not compose.
Brendan Hansknecht (Dec 31 2022 at 12:28):They require libraries in the host language to compose
Leander Behr (Dec 31 2022 at 12:28):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
Brendan Hansknecht (Dec 31 2022 at 12:32):As for a library that depends on a platform. It depends. Generally speaking there are two main options:
Brendan Hansknecht (Dec 31 2022 at 12:33):Honestly neither of these is necessarily optimal. I expect some sort of change as this becomes more common
Brendan Hansknecht (Dec 31 2022 at 12:34):I guess there is a third option: bundle the library with the platform.
Richard Feldman (Dec 31 2022 at 13:56):there are potentially more options in this space with the interpreted effects design, but that's still WIP
Richard Feldman (Dec 31 2022 at 14:26):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!
Luke Boswell (Dec 31 2022 at 15:33):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.
Richard Feldman (Dec 31 2022 at 18:14):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:
Kiryl Dziamura (Jun 25 2024 at 18:20):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 26 2025 at 12:14 UTC