Stream: beginners

Topic: structured roc file headers

Drewry Pope (Jul 12 2025 at 19:58):

hello! is there a good method for getting the roc headers of a given module?

• app

app [main!] {
    pf: platform "./Platform/main.roc",
    lib: "./Lib/main.roc",
}

app [main!] { pf: platform "https://github.com/roc-lang/basic-cli/releases/download/0.19.0/Hj-J_zxz7V9YurCSTFcFdu6cQJie4guzsPMUi5kBYUk.tar.br" }

• module

module [to_str, matrix]

• package

package [
    Hello,
    Goodbye
] {}

• platform

platform "go-basic-cli"
    requires {} { main : Str }
    exposes []
    packages {}
    imports []
    provides [main_for_host]

• hosted

hosted [
    stdout_line!,
    hello!,
]

for each of these types of files what's the ideal way to access?

should i parse the ir expression output into something easier to pass around?

i imagine a format like json yaml or kdl may be ideal.

i could also see something that provides the data decoded into roc primitives,

then a user could encode however they like. that might be most performant?

idk if the data would look like "hosted": ["stdout_line!", "hello!"] or if it would be more like

{
  "type": "hosted",
  "list_data": ["stdout_line!", "hello!"]
  "record_data": {}
}

or something else entirely including access type hash filename etc.

what i really want is to provide a roc file and receive

• module type
• if it has imports, list all import data {alias, url, hash, types}
  • (type includes local, remote, platform)

but i guess i'm asking somewhat generically is the best way to go about any of this kind of meta stuff is it the ir output? maybe a cli flag or builtin or something? i suppose docs may have what i need.

i take parse and extract what i need? how stable is the parse output? (does record-field mean platform?)

(app @1.1-1.57
        (provides @1.6-1.12
            (exposed-lower-ident (text "main!")))
        (record-field @1.15-1.57 (name "pf")
            (e-string @1.28-1.55
                (e-string-part @1.29-1.54 (raw "../basic-cli/platform.roc"))))
        (packages @1.13-1.57
            (record-field @1.15-1.57 (name "pf")
                (e-string @1.28-1.55
                    (e-string-part @1.29-1.54 (raw "../basic-cli/platform.roc"))))))

Anton (Jul 13 2025 at 12:51):

We just had a discussion about how to provide this kind of data: #contributing > zig compiler - LSP @ 💬

Anton (Jul 13 2025 at 12:58):

does record-field mean platform?

Other headers may also have record-fields in them, I'm not sure

Anton (Jul 13 2025 at 12:59):

In parsing. it appears we discard the info that something has the platform keyword, is that correct @Joshua Warner @Anthony Bullard?

Anton (Jul 13 2025 at 13:01):

how stable is the parse output

Small changes are pretty likely in the near future, but I do not expect large changes.

Drewry Pope (Jul 13 2025 at 23:13):

thank you!! I'll look into what I can put together using the parse data. do you have any recommendations for how best I can find which packages import is the platform when viewing parser output?

Luke Boswell (Jul 13 2025 at 23:20):

Keep in mind that we have a bare bones implementation in the parser, we haven't really touch canonicalization for the headers yet AFAIK -- or implemented support for packages etc.

So I think it's quite possible the s-expression will change.

What are you planning on doing with this information? There isn't a lot of 0.1 roc code floating around to work with.

Drewry Pope (Jul 13 2025 at 23:22):

ha, yeah updating a lot of packages is on my list. I want to get the platform and then accept or reject based on the provided platform. also nix experimentally supports blake3 hashing now so I was thinking of trying to improve roc2nix

Drewry Pope (Jul 13 2025 at 23:24):

I totally get that it's all moving around I can pin and upgrade later if I have to I'm not worried about it. :sweat_smile:

Last updated: Jul 26 2025 at 12:14 UTC