Luke Boswell (Nov 03 2022 at 20:12): Luke Boswell (Nov 03 2022 at 20:12):I keep forgetting the host is part Roc. :grinning:
Brendan Hansknecht (Nov 04 2022 at 01:22):Platform is, host isn't if you want to get really technical with naming. The platform is the host and the roc API.
Luke Boswell (Nov 04 2022 at 01:42):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?
Brendan Hansknecht (Nov 04 2022 at 02:08):Generally, we just say platform when talking about things from the roc app/roc developer perspective
Richard Feldman (Nov 04 2022 at 02:54):yeah I wish we had a better name for the part of the platform that's written in Roc!
Richard Feldman (Nov 04 2022 at 02:55):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:
Luke Boswell (Nov 04 2022 at 03:50):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)
Notification Bot (Nov 04 2022 at 03:51):7 messages were moved here from #beginners > Understanding Effects by Luke Boswell.
David Mell (Nov 04 2022 at 04:18):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.
Brendan Hansknecht (Nov 04 2022 at 05:14):Multiple platforms doesn't really make sense with how roc works. Multiple applications on top of a single platform theoretically makes sense in roc.
Brendan Hansknecht (Nov 04 2022 at 05:15):I think with roc used as a scripting language for a game, you could see multiple apps with a single platform
David Mell (Nov 04 2022 at 05:59):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.
Brendan Hansknecht (Nov 04 2022 at 16:03):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.
Brendan Hansknecht (Nov 04 2022 at 16:04):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.
David Mell (Nov 04 2022 at 17:15):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.
Brendan Hansknecht (Nov 05 2022 at 00:11):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.
David Mell (Nov 05 2022 at 02:47):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.
David Mell (Nov 05 2022 at 03:00):Lumping the host and platform together has problems when you think about cases where there are multiple host implementations.
Brendan Hansknecht (Nov 05 2022 at 04:49):A platform is a host and a roc api. So two platforms necessarily means two hosts.
Brendan Hansknecht (Nov 05 2022 at 04:49):But yes, you could have multiple roc apis and a single host theoretically.
Brendan Hansknecht (Nov 05 2022 at 04:51):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.
Brendan Hansknecht (Nov 05 2022 at 04:52):Still exposing the same roc api, but one version the user will have a clear specification of everything the app may access.
Brendan Hansknecht (Nov 05 2022 at 04:54):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.
Brendan Hansknecht (Nov 05 2022 at 04:55):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.
Richard Feldman (Nov 05 2022 at 05:07):you can produce a library with --lib - e.g. that's used in the ruby-interop example
Brendan Hansknecht (Nov 05 2022 at 05:11):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
Richard Feldman (Nov 05 2022 at 05:11):indeed!
Richard Feldman (Nov 05 2022 at 05:13):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
Brendan Hansknecht (Nov 05 2022 at 05:13):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.
Richard Feldman (Nov 05 2022 at 05:13):so "application" is at least distinct from "executable" here!
David Mell (Nov 05 2022 at 05:58):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.)
Brendan Hansknecht (Nov 05 2022 at 15:43):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 26 2025 at 12:14 UTC