rune
rune copied to clipboard
CeleritasCelery
HashMap data structure
In order to map between the Rust and Lisp worlds, we have to handle aliasing. Data structures must be both mutable and aliasable. The "simple" solution to this is to use the a RefCell. However we also need to support the maphash function, which iterates over a hashmap taking a closure.
We need to iterate through a hashmap while also mutating it. Current iterators don't allow this, they expect to borrow the hashmap for the duration of the iteration, meaning we can't borrow it mutabley, even with RefCell.
1 - current solution only get's us half way
The current solution is only a stop gap approach to bootstrap. It allows us to mutate individual values, but we can't add or remove elements from the hashmap. This is done by making the value of a hashmap a Cell.
pub(crate) type HashTableView<'ob, T> = HashMap<GcObj<'ob>, T>;
pub(crate) struct LispHashTable {
gc: GcMark,
is_const: bool,
inner: RefCell<HashTableView<'static, ObjCell>>,
}
2 - create a hashmap that is backed by indexes, then use the index for iteration
Instead of using the hashmap iterator, if we had a hashmap that was indexable, we could use the index for iteration instead of holding a reference. Not sure if a crate exists, or if we would need to implement our own hashmap.
how about we temporarily mark a hashmap as immutable when iterating through it?
Because the lisp code is free to modify the hashmap during iteration. Each iteration cycle we return control back to the lisp VM, and it can add/remove/modify elements in the Hashmap. This even happens as part of the bootstrap.
What behavior do the code that inserts while iterating expect? perhaps we can keep a vector for "objects to be inserted" and insert them after iteration has finished?
Problem is mutation can change what shows up for the next iterator. You can remove elements while iterating or add them. These changes need to be reflected in the objects returned from the iterator.