Stream: API design

Topic: Decoding lists and tuples

Jasper Woudenberg (Jul 23 2026 at 18:23):

I'm happily puffing along porting Rvn to the new compiler. It's a joy, the combination of var and match make for some really concise but readable code I think. I've never felt so little friction writing parsing code.

One thing I noticed is that the parse_array_* functions are used for parsing lists and tuples both. That sort of makes sense for JSON which makes no difference between the two, but for Rvn I think it's problematic. I could in parse_array_start accept both [ and ( as a starting delimiter, store it in state, and then later check the closing paren matches the starting (I'd need to store a stack of parens to support nested structures). That would allow a user to parse an Rvn list into a Roc tuple and vice-versa though, which I'd prefer not to support because if such a situation were encountered I would imagine it to be programmer error.

Any thoughts on having separate parse_tuple_* functions? Or alternatively to pass some indication about whether a list or tuple is expected to the parse_array_* functions?

Richard Feldman (Jul 23 2026 at 18:39):

oh yeah array is like null - it was a quick way to get json up and running but we should replace array with list and tuple

Jasper Woudenberg (Jul 23 2026 at 21:11):

Maybe another point that's also only a temporary API now: For parsing a record parse_record_field gets called a number of times, until you say you're done parsing fields. It'd be convenient to have a parse_record_start and parse_record_after_field method, similar to the ones that exist for parse_array_. That would save the implementer needing to keep track in state whether its parsing the first record (and maybe needs to parse some symbols indicating the start of a record first) or not.

Luke Boswell (Jul 26 2026 at 03:27):

@Jasper Woudenberg -- Rvn is very similar to parsing Roc source... I was wondering if it would be possible to have a Roc source parser that Rvn uses, but also other packages could use. The specific use case I have in mind is pure Roc syntax highlighting for static site generation.

Luke Boswell (Jul 26 2026 at 03:28):

It may be a different use case though... I just had the thought

Jasper Woudenberg (Jul 26 2026 at 08:05):

I think it'd be possible, but it might be quite a bit of work:

• For one thing, Rvn only needs to support data structures. Supporting functions brings in quite a bit of additional syntax.
• Rvn code currently uses the Roc parsing API directly, but that API doesn't support (for legitimate reasons) decoding function values. So I imagine building a general Roc parser that Rvn also uses would require creating some in-between abstractions representing parsed-Roc, that Rvn can then continue to parse into plain Roc values. Maybe there's other ways to do it! My point is that Rvn would need to be "architected" quite differently.

I also think that for static site generation highlighting in Jay (my static site generation project I still need to port to the new compiler), I'd probably continue to build on treesitter for code highlighting, just because that way I get support for many additional languages besides Roc.

Richard Feldman (Jul 26 2026 at 13:00):

also you only need tokenization for syntax highlighting, not a full parser

Richard Feldman (Jul 26 2026 at 13:00):

and that can run much faster

Jasper Woudenberg (Jul 26 2026 at 15:30):

Should parsing tags already work? I'm seeing some methods for it in the standard library, but can't get it to work yet in code.

Attempt on the REPL:

» Ok(Friendly) == Json.parse("\"Friendly\"")

┌────────────────┐
│ MISSING METHOD ├─ This parser_for method is being called on a value whose type doesn't have that method. ─────────────────────────────────────────┐
└┬───────────────┘                                                                                                                                  │
 │                                                                                                                                                  │
 │  main = Ok(Friendly) == Json.parse("\"Friendly\"")                                                                                               │
 │                         ‾‾‾‾‾‾‾‾‾‾                                                                                                               │
 └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── repl:2:24 ┘

    The value's type, which does not have a method named parser_for, is:

        [Friendly, ..]

And when I add the following line to Rvn (to kick off implementation of the tag parsing TDD-style) it makes all my other tests fail with runtime error :laughing:.

expect Friendly == Rvn.parse("Friendly".to_utf8())?

Richard Feldman (Jul 26 2026 at 15:52):

those are both bugs; I'll take a look!

Last updated: Aug 12 2026 at 12:35 UTC