Just looking at the pinned task https://github.com/roc-lang/roc/issues/664
I've added a couple of related PRs. Just have a couple of questions.
parseI16
, parseDec
... etc functions or might this be covered somewhere else? parseF32
, do we just pick a standard like IEEE 754, or perhaps defer to zig's std.fmt.parseFloat implementation?Str.dropPrefix
and Str.dropSuffix
these should be implemented using a zig builtin also right?Otherwise I think will be of the builtins completed -- so we're close.
I think with the map2-based record builders landed, there's no more need for map3 and mapN beyond map2 for Result or Task
For 2 and 3, I'd defer to Zig, yes. I trust Andrew + team to make good decisions here on behavior and performance.
For 1, I think these are useful, and I'm not sure how to implement them in a third-party package without unnecessary allocations, so having them as builtins seems like the move.
So yes, the map2's are still good, the mapN's are not needed, and everything else can be done with zig (ideally with zig builtins).
I think the prefix and suffix stuff could be implemented in roc, but zig is also fine. All it is is a sublist + equality followed by a potential second sublist. Just need to be careful around unicode to avoid costs of checking the entire string, but that should be doable with some sort of unchecked Str.fromUtf8
Yeah, I think we still need parse functions. Probably would have an API that returns a value plus the rest of the string after parsing.
Those I would defer to zig for simplicity
Oh wait, those parse functions aren't parse functions at all.....
I don't think we want this:
parseI16 : List U8, Endi, Nat -> Result I16 [ NotEnoughBytes ]*
I think we want something like
Str.parseI16 : Str -> Result { val: I16, rest: Str } [WhatEverErrorsParsingCanProduce (invalid format? Not a number? Out of bound?)]
Maybe also want it on List U8 which assumes parsing from ASCII.
Last updated: Jul 06 2025 at 12:14 UTC