Repository navigation
Define on-disk format for pathmap vals that can be used by ACT, .paths, and trace #170
Description
See #166 (comment) and #165 (comment)
We want something that lets values be written to a file. We probably want a hash-map-style table with 64-bit keys. I think we want identical keys to imply identical data. I.e. the key is a stable hash.
I think the target is write-once, so mutability and garbage collections are not requirements.
The jury is still out on whether the encode & decode behaviors are implemented via a trait or via callbacks. A trait makes the API nicer at the expense of the orphan rules boxing out implementations on types for third-party crates, and primitives we didn't supply implementations for.
I don't think serde is a good fit because it's higher overhead than we want and we probably want tighter control over our own destiny.
I think we probably want to limit the deserialize method to Copy types, so it will be possible to mmap one of these files and return &V. Even then we may need a trait to ensure we get a stable repr.
Activity
Limiting values in trace format to () and u64 until we address #170
adamv-symbolica commentedon Oct 28, 2026
I believe the .paths format makes the correct call here, where it allows the user to specify both the serialization and the reference to that serialized value, and doesn't make any judgement about a) storing to file, b) id's VS value-based identity, and c) how to represent that in the format.
From a user-implementation side, they most-likely don't want this, but either inline values if they're small enough, contiguous id's if the values are large and the same size, tagged id's if there's a tagged union value type into an arena style format, or direct file offsets if there's a wide range of sizes like with strings.