Stream: compiler development

Topic: Builtins to implement

view this post on Zulip Luke Boswell (Aug 14 2024 at 03:31):

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.

  1. Do we still want all the parseI16, parseDec ... etc functions or might this be covered somewhere else?
  2. How would we implement something like parseF32, do we just pick a standard like IEEE 754, or perhaps defer to zig's std.fmt.parseFloat implementation?
  3. Do we still want all of the Result.map<N> combinations?
  4. For 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.

view this post on Zulip Sam Mohr (Aug 14 2024 at 03:34):

I think with the map2-based record builders landed, there's no more need for map3 and mapN beyond map2 for Result or Task

view this post on Zulip Sam Mohr (Aug 14 2024 at 03:43):

For 2 and 3, I'd defer to Zig, yes. I trust Andrew + team to make good decisions here on behavior and performance.

view this post on Zulip Sam Mohr (Aug 14 2024 at 03:44):

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.

view this post on Zulip Sam Mohr (Aug 14 2024 at 03:48):

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).

view this post on Zulip Brendan Hansknecht (Aug 14 2024 at 04:23):

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

view this post on Zulip Brendan Hansknecht (Aug 14 2024 at 04:24):

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.

view this post on Zulip Brendan Hansknecht (Aug 14 2024 at 04:24):

Those I would defer to zig for simplicity

view this post on Zulip Brendan Hansknecht (Aug 14 2024 at 04:25):

Oh wait, those parse functions aren't parse functions at all.....

view this post on Zulip Brendan Hansknecht (Aug 14 2024 at 04:26):

I don't think we want this:
parseI16 : List U8, Endi, Nat -> Result I16 [ NotEnoughBytes ]*

view this post on Zulip Brendan Hansknecht (Aug 14 2024 at 04:28):

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 26 2025 at 12:14 UTC