Richard Feldman (Jun 11 2025 at 16:25): Richard Feldman (Jun 11 2025 at 16:25):I was thinking about the beginner experience and the scripting idea: what if roc shipped with a CLI platform that was approximately as featureless as basic-cli today?
Richard Feldman (Jun 11 2025 at 16:26):2 main reasons I was thinking about this:
Richard Feldman (Jun 11 2025 at 16:28):roc itself. every language that's good at scripting has this, and we can't unless we offer a platform out the box that's good for scripting Richard Feldman (Jun 11 2025 at 16:30): Richard Feldman (Jun 11 2025 at 16:33):the specific idea I had is:
cli: platform (no url) and that just gets you this platformapp header, and that essentially desugars to app { cli: platform } - this would be primarily for beginners, but scripts could reasonably do it too Richard Feldman (Jun 11 2025 at 16:34):this specific platform being offered out-the-box in the roc cli seems fine because it only needs all the OS things the Roc CLI itself would need
Richard Feldman (Jun 11 2025 at 16:35):e.g. it doesn't need to deal with databases or anything like that (I wouldn't put SQLite in the out-the-box one)
Richard Feldman (Jun 11 2025 at 16:36):and for the wasm target we could have it compile to a wasm entrypoint that says "I need all these functions to be provided from js" and then it's up to you to make those available via js (e.g. in an online Roc playground)
Richard Feldman (Jun 11 2025 at 16:46):thoughts?
Richard Feldman (Jun 11 2025 at 16:57):oh yeah, two implications of this (which we'd also discussed previously as being a possibility, and which this would resolve in an obvious way): we'd want Path and the Http request and response data structures to be builtins
Anton (Jun 11 2025 at 17:33):Sounds good, it is indeed a big simplification for the user
Anton (Jun 11 2025 at 17:35):you can do
cli: platform(no url) and that just gets you this platform
That syntax feels a bit weird to me, I think because it's an omission with a substantial difference in meaning.
Anton (Jun 11 2025 at 17:35):if you like, you can omit the entire
appheader
That feels like the way to go for me
Brendan Hansknecht (Jun 11 2025 at 18:33):How does it get updated?
Brendan Hansknecht (Jun 11 2025 at 18:43):Also, is it a compiler platform or just run through the interpreter?
Richard Feldman (Jun 11 2025 at 19:49):it's only updated with the language
Richard Feldman (Jun 11 2025 at 19:50):and yeah it would in every way behave like a totally normal platform except that its location is the compiler binary rather than a url or local path
Brendan Hansknecht (Jun 11 2025 at 20:16):I guess this should be mostly stable, so probably fine.
Luke Boswell (Jun 11 2025 at 22:15):every language that's good at scripting has this, and we can't unless we offer a platform out the box that's good for scripting
This is framed as a downside, but I see this as a positive.
Imagine I'm an IT manager and I am reviewing a request to add roc on my network. If I can isolate it and whitelist platforms that are available, it will be much easier for me to evaluate the security boundary and approve the request.
Luke Boswell (Jun 11 2025 at 22:16):I guess the API for this builtin platform would be very simple, so maybe it's not a big deal or anything... but where do we draw the line?
Brendan Hansknecht (Jun 11 2025 at 23:13):Oh also, does this default to a secure cli or basic cli and will it support both?
Luke Boswell (Jun 11 2025 at 23:33):In my workplace we have everything locked down pretty hard. If you need something like python to write a script, it's really painful and a lot of paperwork to get approval and even then it's only in a very isolated environment.
I've been looking forward to a future where roc could live on our systems, and we could have custom platforms (or whitelisted ones like "safe-cli") available for use. But I may be dreaming
Richard Feldman (Jun 12 2025 at 02:01):if you had a list of approved platforms anyway, the out-the-box one could either be on or off that list just like any other platform :smile:
Richard Feldman (Jun 12 2025 at 02:02):Brendan Hansknecht said:
Oh also, does this default to a secure cli or basic cli and will it support both?
I could see arguments either way. I think the bigger question is whether to do it at all.
Brendan Hansknecht (Jun 12 2025 at 02:09):In my mind if this ends up subverting secure cli, it is less useful... But making it support both with a cli flag (or even better an environment variable) could be great.
Luke Boswell (Jun 12 2025 at 03:12):I wonder how much work the "secure" part of secure-cli is? Would it be feasible to make this builtin cli platform a secure one (even if it's very limited on features).
Maybe by default it isn't permitted to really do anything other than stdio without a user prompt. You could use a flag --disable-prompts to stop any prompts on e.g. opening a file or sending a HTTP request etc.
Anton (Jun 13 2025 at 09:01):Yeah for people that like using locked down platforms, having an unrestricted platform easily available may be a turnoff.
Anton (Jun 13 2025 at 09:03):If typical scripting use requires extra flags we are reducing the convenience gained by having basic-cli included.
Kevin Gillette (Jun 13 2025 at 14:19):Why not a special string syntax instead, like "builtin:cli" ? That means you don't need a special case in the grammar itself, and is (in my mind) more intuitive/obvious what's going on to the casual reader.
Kevin Gillette (Jun 13 2025 at 14:23):I'll also recommend having some kind of basic versioning in place of what would typically be the verification hash, like v1, v2, etc (start with v0 and no promises), so that you can still change things later while not breaking people. Since these changes probably won't happen often, it shouldn't be too hard to maintain multiple versions.
Richard Feldman (Jun 13 2025 at 22:32):Why not a special string syntax instead, like "builtin:cli" ?
I strongly prefer to avoid that. Ideally, string literals are just plain content and don't have any secret meaning to the compiler when you choose just the right string. Same with comments.
Richard Feldman (Jun 13 2025 at 22:34):Kevin Gillette said:
I'll also recommend having some kind of basic versioning in place
I don't think the CLI should ship multiple versions of this platform. Just like the stdlib, there's just the one version. :smile:
Richard Feldman (Jun 13 2025 at 22:39):Anton said:
Yeah for people that like using locked down platforms, having an unrestricted platform easily available may be a turnoff.
this is a fair point, although I still think whatever solution they end up wanting for "only these specifically enumerated platforms can possibly be used" should cover the builtin platform use case as well.
Richard Feldman (Jun 13 2025 at 22:47):like for example, if I'm concerned that anyone can run roc abc.roc and have that do a bad thing specifically because of the platform it's using, then I already have that concern today. If the machine in question doesn't have arbitrary Internet access, so I'm not worried about https platforms, there's still the concern about loading platforms from local file paths. And if I can load platforms from local file paths, and any other part of the system can write bytes to local files, then roc can still be used to run other platforms.
Richard Feldman (Jun 13 2025 at 22:50):so I think there are two scenarios that make sense to me:
roc with approved platforms, but it's not enforced in software - it's just a policy.roc binary which only runs platforms listed in an env var (and refuses to run any others, including the builtin platform, at which point it might as well not be in that binary) Brendan Hansknecht (Jun 13 2025 at 23:15):Richard Feldman said:
Kevin Gillette said:
I'll also recommend having some kind of basic versioning in place
I don't think the CLI should ship multiple versions of this platform. Just like the stdlib, there's just the one version. :smile:
Won't this be really problematic....sorry, can't run that script, it is too old of a basic cli version.
Brendan Hansknecht (Jun 13 2025 at 23:17):Like you don't want all cli scripts to be so tightly couple to roc version
Richard Feldman (Jun 13 2025 at 23:20):same problem as "too old a version of the language" right?
Brendan Hansknecht (Jun 13 2025 at 23:50):I don't know platform tend to update with a much different frequency to the compiler. Feels more like the same concerns we have for unicode
Brendan Hansknecht (Jun 13 2025 at 23:50):Though not as bad
Luke Boswell (Jun 14 2025 at 00:45):Richard Feldman said:
- for the scripting use case, it would be really desirable to be able to distribute scripts that are a single file and have no dependencies whatsoever, including an internet connection, other than
rocitself. every language that's good at scripting has this, and we can't unless we offer a platform out the box that's good for scripting
How are people going to be getting roc? If it's through a script or something, could we have it bundle/download and cache some popular platforms like basic-cli, basic-webserver, which could be used for hello-world.
distribute scripts that are a single file and have no dependencies whatsoever, including an internet connection
I don't really understand why this is desirable. Is it that it "just works"?
We've now coupled the language with the platform and that introduces the other issues like maintenance, versioning.
Luke Boswell (Jun 14 2025 at 00:46):it would be great for the beginner learning curve to be able to introduce the concept of platforms later, after the beginner has had a chance to actually build something.
On the flip side, it's also now another concept that the beginner has to understand, "the platform string can be this or that".
Luke Boswell (Jun 14 2025 at 00:47):I'm not trying to be negative. Just trying to think of potential downsides to the proposal.
Richard Feldman (Jun 14 2025 at 01:06):the "no dependencies" desirability is so that you don't have situations like you download the script but then it can't actually run without internet access even though it doesn't really need internet access to do its job
Richard Feldman (Jun 14 2025 at 01:07):a random thought I hadn't considered until just now: what if we only bundled safe-script with the roc cli?
Richard Feldman (Jun 14 2025 at 01:08):so for beginners we can teach you hello world, reading from stdin, etc
Richard Feldman (Jun 14 2025 at 01:08):then we get to file I/O and it's like oh now you have this prompt that you can't get around. Yay security, but let's actually switch platforms to basic-cli so we don't have this prompt every time.
Richard Feldman (Jun 14 2025 at 01:09):and then we're introducing platforms as like "yeah it's an extra line of code but actually we're adding convenience here"
Richard Feldman (Jun 14 2025 at 01:10):and then there's no security concern bc the only thing that ships with the roc cli is the sandboxed one anyway
Richard Feldman (Jun 14 2025 at 02:08):a downside of that idea is that it might give people a false sense of security about running a .roc file without reading it, not realizing it might be specifying a different platform
Brendan Hansknecht (Jun 14 2025 at 06:17):In my mind the biggest flaw with this is that the user still has to check the platform and make sure there is no platform line. Also, if most scripts use basic cli for more features and convenience, I still need the safe script version of basic cli.
Jasper Woudenberg (Jun 14 2025 at 08:55):A question I have is how we imagine Roc beginners will enter the Roc ecosystem once it's taking off a bit. Do we imagine most people will learn about Roc first, then start looking for a platform that allows them to build whatever they want to make (app store model)? Or do we imagine folks will see an impressive demo about, say, building an Android app using some Roc platform, they check it and get to know Roc that way (Ruby on Rails model)?
The beginner experience might be nicest if the platform takes ownership for onboarding beginners. That way, depending on what the beginners is looking to build hello-world will a website or a CLI or a GUI or an app, and teaching Roc the language will go hand in hand with building increasingly sophisticated software in the platform's domain. Kind of like the Elm guide.
A challenge in this model is figuring out how to make knowledge on good ways to teach Roc available to platform authors in such a way that they can include great beginners experiences in their platform, in a similar fashion to how Roc aims to equip platform authors to build good tooling, test support, and docs for their platform.
Jasper Woudenberg (Jun 14 2025 at 09:15):
- for the scripting use case, it would be really desirable to be able to distribute scripts that are a single file and have no dependencies whatsoever, including an internet connection, other than
rocitself. every language that's good at scripting has this, and we can't unless we offer a platform out the box that's good for scripting
Another way to dice this would be to figure out a way the platform can be an installable that includes Roc itself. Then basic-cli could be the single thing you download to do scripting. It might still install itself in such a way that you end up with a general Roc binary that could be used for working with other platforms in the future.
Versioning is less of a concern this way, because roc-cli will update more frequently than Roc.
Plus, for scripting in particular it might be nice if the platform choice moves into the shebang, that way small Roc scripts can be as compact as bash scripts.
Isaac Van Doren (Jun 15 2025 at 15:16):
- for the scripting use case, it would be really desirable to be able to distribute scripts that are a single file and have no dependencies whatsoever, including an internet connection, other than
rocitself. every language that's good at scripting has this, and we can't unless we offer a platform out the box that's good for scripting
It seems like in pretty much all scenarios, a user is going to download Roc from the internet and then run something. They already need to have an internet connection to download Roc, so also needing an internet connection to download the platform doesn't seem like much of an issue.
Isaac Van Doren (Jun 15 2025 at 15:18):Instead of bundling a platform with the binary, we could make it so that if you omit the platform header, the latest version of basic cli will be downloaded and used. That way we could avoid teaching beginners about platforms for a while, and we wouldn't need to introduce a new extra-limited platform into the binary
Tobias (Jun 16 2025 at 09:02):I don't know about "the scripting use case".
For smaller programs people don't want to bother with complex builds. Historically that suggested an interpreted language. But compiling roc is easy!
Most "scripts" interact heavily with the system. In the beginning Perl was mostly a wrapper around the POSIX C API. How would a stripped down platform help with that?
Anton (Jun 16 2025 at 10:01):For smaller programs people don't want to bother with complex builds. Historically that suggested an interpreted language. But compiling roc is easy!
Yeah, from the perspective of the user, running a roc script is not more complicated then running a python script.
Anton (Jun 16 2025 at 10:04):In my mind, Roc's checking of the code before it is run is a massive advantage for scripting, because compile errors are almost always easier to fix then your typical runtime python crash.
Tobias (Jun 17 2025 at 02:38):@Anton
Yeah, from the perspective of the user, running a roc script is not more complicated then running a python script.
I meant that compiling a regular roc program is not more complicated, so I don't see that need for a special platform.
Anton (Jun 17 2025 at 06:25):Yeah, the special platform was just for security, because basic-cli allows pretty unrestricted access.
Notification Bot (Jun 17 2025 at 06:25):A message was moved from this topic to #ideas > cli Cmd API by Anton.
Last updated: Jun 16 2026 at 16:19 UTC