Jonathan (Mar 01 2026 at 19:00): Jonathan (Mar 01 2026 at 19:00):I couldn't seem to find an insert method for List, so I thought I'd implement it for now with concat, but I was also wondering if there would be a concatMany so only one array would be allocated instead of two separate (1 - appended = left_sublist + item, 2 - inserted = appended + right_sublist). Are either of these planned (or implemented and I missed!), or left for more random-insert-friendly data structures?
Luke Boswell (Mar 01 2026 at 19:41):The old docs for List are still helpful even though they use the old syntax. As far as I know that is what we are porting across without any major changes
https://www.roc-lang.org/builtins/alpha4/List/
For insert friendly data structures I imagine you are looing for Dict ... but I dont think it's been implemented yet.
Jonathan (Mar 01 2026 at 19:50):Ah I see - join from the old compiler would be what I need. I might try and implement some, particularly those that could be done in roc-land not zig?
And for alternative data structures, I meant I think other implementations of arrays that use trees under the hood (I think Scala Vector and Clojure PersistentVector are some examples?)
Luke Boswell said:
but I dont think it's been implemented yet.
I was trying to learn about and implement a HAMT in roc as an exercise in lieu of an available dict, but it's been slow progress ^^
Anton (Mar 02 2026 at 16:15):Feel free to add List.join to Builtin.roc, it's ok to implement that one in Roc, someone else can implement a low-level version later if that is worth it.
Anton (Mar 02 2026 at 16:22):List.insert may be added as well
Anton (Mar 02 2026 at 16:25):implementations of arrays that use trees under the hood
LLVM may be able to optimize list operations well enough so that this does not matter for release builds, but it could be worthwhile for the dev backends.
Brendan Hansknecht (Mar 05 2026 at 02:03):I think HAMT data structures could be built in Roc userspace if someone really need that for some reason.
Jonathan (Mar 05 2026 at 08:25):I was actually wondering how much Roc would benefit from persistent data structures implemented in userspace, if there's mutation for singly held data (and I'm understanding that right)?
Jonathan (Mar 05 2026 at 08:26):I wouldn't say I really need it anyhow :smile::smile: Just an excuse to try it
Steve Howell (Mar 05 2026 at 10:34):When I was doing Elm, at least two of the big persistent data structures were written purely in Elm, and it was super educational for me to read that code. So at the very least, anybody who builds similar things in Roc will probably benefit some folks in the community. Maybe I'm kind of unique, in that I had never really learned about basic data structures like red-black trees. I ended up understanding them just from reading Elm code and made silly toys like this: https://showell.github.io/redblack.html
Jonathan (Mar 05 2026 at 10:40):What a great visualization, thank you! I also never really did much algorithms/datastructures. I had just understood RB as a set of rules that by construction helped maintain balance, but it's really nice to see all those nodes shunt along to the left to balance.
Steve Howell (Mar 05 2026 at 10:46):@Jonathan Thanks for looking at it! I think I just doubled my audience for that project. (It was honestly just a labor of love...learning Elm was so much fun, and I did other things like that just for pure exploration.)
Steve Howell (Mar 05 2026 at 10:47):And, yeah, that's ultimately how I understand a lot of data structures--the whole trick is how they maintain their invariants, which are usually simple things like "balance", in an elegant way.
Brendan Hansknecht (Mar 05 2026 at 20:20):I was actually wondering how much Roc would benefit from persistent data structures implemented in userspace, if there's mutation for singly held data (and I'm understanding that right)?
I think there are definitely use cases, but I do agree that generally, it probably would not be worth using.
A simple example that would help is some sort of list that requires history tracking so you can revert back to old versions. In roc, you would constantly duplicate that list. With HAMT, it is basically free to still reference the old version. This is essentially how some COW filesystems do snapshotting.
Jonathan (Mar 05 2026 at 20:30):Will the future Roc Dict most likely be a 'standard' hash map? I'm curious because I'm not sure (/haven't kept up with) what the plan is with abilities like Hash, and how they can be implemented for user types. The most recent message about it afaict is yours Brendan -- that it will likely involve compiler magic?
Brendan Hansknecht (Mar 05 2026 at 20:32):Dict is currently, and will remain (though probably will be moved to a zig implementation instead of roc) an indexmap. This is essentially a flat hash map that remember insertion order.
Brendan Hansknecht (Mar 05 2026 at 20:33):Hash will be implementable in users space. It also should have compiler magic to auto-derive it. So most users will probably never implement it.
Brendan Hansknecht (Mar 05 2026 at 20:33):You only need to implement it if you intentionally want to skip fields in the hash.
Jonathan (Mar 05 2026 at 20:45):Brendan Hansknecht said:
Dict is currently, and will remain ...
Do you mean that it's available in Roc nightly too?
Jonathan (Mar 05 2026 at 20:46):Or just that when it gets ported over it will remain the same as the old stdlib(I might have missed it if it's already there, sorry, but didn't spot it in Builtins)
Luke Boswell (Mar 05 2026 at 21:41):Yeah when it's ported
Jonathan (Mar 05 2026 at 22:05):Thank you guys, I have many questions but I'll leave it there now we're thoroughly off original topic :smile::smile:
Last updated: Mar 20 2026 at 12:28 UTC