Promoting rescript-vector to a primitive data structure

[cometkim]

Suggesting integrating @namenu's persistent vector library with the compiler.

https://github.com/reason-seoul/rescript-collection/tree/main/packages/vector

This library implemented in pure ReScript is optimized for changing the last element, unlike a list optimized for changing the head (first element).

This is useful if a user needs an Array-like structure but an immutable one. It is faster than the ImmutableJS and Mori, which are homogeneous libraries available in JS. (See benchmark)And its stability has been verified with fuzz tests.

It is available today in any ReScript project, but integrating it with a compiler can provide list-like ergonomics. For example:

let v = vec{1, 2, 3, 4, 5}

let last = switch v {
  | vec{..._init, last} => Some(last)
  | vec{} => None
}

[cristianoc]

This could fit nicely with a data structure library to go alongside Core. While Core is for basic JS functionality, this other library, let's call it Data for this dicsussion, would be specifically for data structures. It would include the data structure part of Belt, and vectors would fit very well in it.

Later on, one could consider deeper integration with the language. Curious about the pattern matching on the last element, and how common it is going to be. Got some nice examples?

@zth thoughts?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fhammerschmidt]

i guess this could still be nice

[cometkim]

More than ever. As we're sunseting OCaml std and Belt, we need a high-quality DS library

[zth]

I guess having it as a separate installable package makes sense though, right?

[cometkim]

Yes. I believe we already discussed somrwhete making the@rescript/data package

[fhammerschmidt]

Can it somehow also extend existing Core modules? There are a lot of convenience functions in Belt that I'd miss like Array.partition.

[cometkim]

I think it depends on the goal of the Core.

If it prefers thin, mostly zero-cost bindings, I'd like to split the layer rather than directly replace Belt (like Jane Street's Core and Base).