Jasper Woudenberg (Jun 06 2025 at 19:56): Jasper Woudenberg (Jun 06 2025 at 19:56):I just had a thought for a type of Roc platform that hadn't occured to me before, I wanted to share in case others might find it intersting too.
I have a directory with markdown files that serve as a kind of low-tech personal wiki. I was writing a shell command for searching through the directory to find and open one matching a search term. I built it using a combination of ripgrep for finding matching files, then piping that into fzf which presents a fuzzy-selector in the terminal to pick the file to open.
Now that entire script might be a good fit for writing in basic-cli, but here's another thought: it might be a cool idea to write a Roc platform wrapping Ripgrep and another for wrapping/replacing FZF, providing an alternative API to typing command line arguments. Put concretely, if this is my script now:
rg <many params> | fzf <many params> | xargs $EDITOR
It could become this:
./my-search | ./my-select | xargs $EDITOR
With ./my-search and ./my-select both Roc scripts, each using a dedicated platform for just that type of CLI tool.
Ripgrep and FZF are both amazing tools, but I don't love the process of getting to a set of configuration options that works for a given task, and I imagine a Roc API for constructing configuration for a complicated command will be much nicer to work with than an API made up of command-line flags. The platform could offer some testing primitives for testing the command behaves as expected, it could be really nice!
This wouldn't replace one-of/spur-of-the-moment uses of these commands because I wouldn't want to create a whole separate Roc script for that, but for longer living helper scripts I think it'd be a good fit. Maybe there's other tools for which this treatment might be nice. Finally, these platforms could individually be small, which might be interesting for folks wanting to get into platform development.
Does this sound appealing to anyone else?
Hannes (Jun 07 2025 at 02:47):This sounds similar to a use case for Roc I've wanted to try for a while, which is using Roc as a replacement for jq. I always forget the syntax for anything complex in jq, but I know the roc syntax very well!
Jasper Woudenberg (Jun 07 2025 at 06:49):Oh yeah, a jq-alternative-as-a-Roc-platform sounds amazing!
Anton (Jun 07 2025 at 08:47):Definitely sounds like an interesting experiment! It would be cool to have an enhanced debugging experience for jq, I've spent a lot of time debugging jq pipelines
Luke Boswell (Jun 07 2025 at 09:50):Probably dont need a custom platform. Ive made roc libraries that provide a DSL that basically wraps an API, and that works nicely.
I think the graphing library is one example.
Luke Boswell (Jun 07 2025 at 09:51):https://github.com/lukewilliamboswell/plume
Luke Boswell (Jun 07 2025 at 09:51):I could imagine a DSL that provides some helpers and type safety for jq and just uses basic-cli.
Brendan Hansknecht (Jun 07 2025 at 15:04):I feel like a custom platform or even something that directly integrates with the interpreter might be important for the UX of very quick scripts
Jasper Woudenberg (Jun 07 2025 at 17:45):It'd definitely be nice to have these kind's of affordances in something like basic-cli as well, as a library, but I can see some benefits of doing it as a separate platform too.
For instance, Ripgrep I believe is a rust project and it's also available as a rust library. A platform could build directly on top of that and make use of all the work that went into making ripgrep so fast.
The FZF platform would need to listen to STDIN for keyboard input, then render a terminal UI over stderr and present a final selection over STDOUT. That might make it a bit of an advanced project, even with the help of a library. But an FZF-like platform could hide all that wiring and present a completely pure/non-IO API to the user, and so be super approachable.
Jasper Woudenberg (Jun 07 2025 at 17:53):The more I think about it the more I like this hypothetical jq-alternative platform.
I guess the platform could be as straight-forward as:
main: a -> bAnd as a user you just have to supply a main that performs the transformation you want.
Hannes (Jun 08 2025 at 05:51):Yeah that's exactly why I liked the jq platform, jq does almost exclusively pure transformations.
grep/rg is similar in that regard, although the hardest part of that is normally writing the regex, which a Roc platform won't be able to help with very much. I know some people prefer to use regex builder libraries, but I don't have any experience with them. You could ask the user for a main function that uses parser combinators to extract a sub string from stdin as an alternative to regex, but at that point you're quite far from the rg experience.
find/fd and sed/sd are other tools that could be Roc platforms, although I've never written a complex enough fd command that would benefit from being written in Roc.
I think the power of Roc is closer to something like awk, which is more like a full language. A Roc platform designed for processing text could be useful for people like me who never learnt awk or perl.
Last updated: Jun 16 2026 at 16:19 UTC