I did some Nat
removals and realized that the implementation Dict
uses Nat
extensively, including in the record that represents it
@Brendan Hansknecht if we made the record itself opaque, do you think replacing the remaining usages of Nat
in there is feasible?
or should we explore some way of trying to keep Nat
around behind the scenes, and only used by Dict.roc
internally?
I think the record is already opaque
Should be fine to just change everything to u64 since that is what list indices will use.
er sorry, I mean opaque and implemented behind the scenes, like how List
is
like for example, this: https://github.com/roc-lang/roc/blob/cd7a031d09fcd0a2f95cb2933b675028cd0b7730/crates/compiler/builtins/roc/Dict.roc#L92-L111 includes dataIndices : List Nat
if we change that to List U64
, then Dict
s will take up another 4B on the stack on 32-bit targets for no benefit
Oh yeah, it's an index map so it stores nats....
I mean long term we need to deal with hashing differently on 32 bit systems among other things
I think it would be fine for now to just make this a 64bit dict implementation and add a to-do for 32bit.
works for me! :thumbs_up:
Also, long term, I'm not 100% sure we want to keep dict in roc. We may want to move it to zig. I tried a few times to port the final optimizations over, but kept getting perf regressions. I think the fine details of the dict impl may be a tiny bit low level to happily map to roc, but maybe a few more builtins or simd stuff could fix that....not fully sure.
Is the plan to remove Nat from the language entirely or just to stop using it internally?
entirely
well, will be used internally still like for list indices
Interesting, what's the motivation for that?
It is one of the only target specific parts of the language
Without it, theoretically all roc code (aside from when panics happen) will do the exact same thing no matter the target
This means you can just run pure roc tests once instead of once per platform
previously discussed at https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/replace.20Nat
There were others too
:point_up: yeah, that has more
Ah yeah that sounds like a good change, cool!
anyone know why decoding tuples uses Nat
? @Ayaz Hafiz maybe?
looks like index into the tuple
yep
the choice of integer type there doesn't matter
nice, thanks!
got it compiling, but still plenty to do: https://github.com/roc-lang/roc/pull/5923
Last updated: Jul 06 2025 at 12:14 UTC