I keep forgetting the host is part Roc. :grinning:
Platform is, host isn't if you want to get really technical with naming. The platform is the host and the roc API.
Cool, so Roc API + (rust/c/swift/etc) Host = Platform. :+1: I guess any Roc application can only see the Roc API, so would it be a good idea/should I refer to these parts as Platform API and Platform Host?
Generally, we just say platform when talking about things from the roc app/roc developer perspective
yeah I wish we had a better name for the part of the platform that's written in Roc!
the terminology we have right now is that Platform breaks down into two pieces:
I don't know what should go in the blank though :sweat_smile:
Some brainstorming...
Host <> Framework <> App (like exposing common functionality)
Host <> Controller <> App (takes charge of the platform)
Host <> Super <> App (host supports the Roc api)
Host <> Attendant <> App (like hotel)
Host <> Gateway <> App (like for an API)
Host <> Strata <> App (like a geological rock layer)
7 messages were moved here from #beginners > Understanding Effects by Luke Boswell.
Is app even the correct name for the thing that is built on top of a platform? In the case of a modular application, you could imagine having multiple apps per platform, and even multiple platforms.
Multiple platforms doesn't really make sense with how roc works. Multiple applications on top of a single platform theoretically makes sense in roc.
I think with roc used as a scripting language for a game, you could see multiple apps with a single platform
Game scripting is a perfect example of a case in which you actually might want different platforms. You don't necessarily want every script to be able to do anything for pipelining reasons. Having multiple platforms also doesn't mean you can't share a large portion of the platform types.
Just for clarity, multiple platforms doesn't really make sense because that would mean having multiple executables. So a game that is multiple platforms would have to be multiple executables, which is not normal.
Though i guess this maybe points to wanting multiple platform exposed roc apis such that you can control what is available for each individual script written in roc.
You don't need multiple executables. If you are going to have multiple scripts with the same platform, then you are already going to be building them as dynamic libraries.
If there were to only be one script for each platform, then you could conceivably do multi-way surgery to produce a single executable.
If you have two platforms, you have two chunks of non-roc code that are expected to generate executables. There is no way to merge those two.
You're talking about two hosts. I'm talking about two roc platform specifications for the same host. A host can also produce a library that is used by an executable, not just the executable itself. The way I see it, a platform is a type boundary that both the host and "app" depend on.
Lumping the host and platform together has problems when you think about cases where there are multiple host implementations.
A platform is a host and a roc api. So two platforms necessarily means two hosts.
But yes, you could have multiple roc apis and a single host theoretically.
Also yes, two different platforms could have the exact same roc api, but different host implementations and languages. One example is a cli app and a secure cli app. For the secure cli app, all file access and what not explicitly asks for user permission when the app requests to load a file for example.
Still exposing the same roc api, but one version the user will have a clear specification of everything the app may access.
That said, multiple roc apis for a single host may not really make sense in practice. It would really just be one larger roc api for the single host. Though segregating the roc apis and apps would be useful in some cases.
A host can also produce a library that is used by an executable, not just the executable itself.
That is not currently possible with how roc is planned to work.
you can produce a library with --lib
- e.g. that's used in the ruby-interop
example
That is different though, that is the roc app as a dynamic library rather than surgically linking to a host that is a library that will be link to another host to become and executable
indeed!
David Mell said:
Is app even the correct name for the thing that is built on top of a platform? In the case of a modular application, you could imagine having multiple apps per platform, and even multiple platforms.
I think this will be very unusual I'm not sure what a better name would be than application :big_smile:
like for example the roc
executable will someday expose functionality that relies on at least 2 different platforms:
roc glue
, where you can specify a .roc
file to generate bindings from Roc to another programming languageroc edit
where you can specify editor plugins as Roc applicationsthose two use cases would have totally different APIs, but they would be part of the same roc
executable
I guess strictly speaking, everything is just assembly and object files at the end of the day, so it is possible to make it work if really wanted. Make roc dump a bunch of object files and the manually link, but that isn't really the plan for normal roc use.
so "application" is at least distinct from "executable" here!
Multi-way surgery was just a thought experiment. My objection primarily has to do with the case of using roc as a scripting/plugin language as part of an application. (In my opinion, one of the most powerful use cases.) In which case, each plugin type would have a platform, and each plugin would be an "app". (Not to say I have figured out a better name.)
I see. Yeah, we definitely have to work on that use case. No proof of concept has really been done. I think the goal would be: one host in another language, multiple roc platform apis, and multiple apps that match with individual platform apis.
Last updated: Jul 05 2025 at 12:14 UTC