Purpose of salsa::Update ?

[arialpew]

The book never talk about salsa::Update macro, but it's used in the calc example in Statement and Expression.

From my understanding :

• Tracked struct : stored inside Salsa db, changes are tracked. Constructor automatically provided by macro. New tracked struct should replace the old one on change (it's still unclear at which granularity since you can embed non tracked struct inside, and what's the purpose of no_eq). Can be returned from tracked function. Can contain tracked struct and update struct. Represented as an opaque handle (Id), and should be resolved with Salsa db.

• Update struct : stored inside Salda db (or not ?), changes are tracked. Constructor is user-defined. Can be returned from tracked function. I would say the best explainer is it make the datastructure trackable for Salsa, but I don't know how this apply concretely (based on recursively calling PartialEq for all fields ? There's also specialized impl for std datastructure like HashMap, Vec, ...).

Still, it's unclear how both relate to each other, and which one to use.

[nikomatsakis]

Yeah, the book is out of date, sorry about that.

Any structs or enums that you put inside a tracked struct need to derive the Update macro-- we provide a Derive for you. Salsa structs (tracked structs, interned structs) already implement Update.

Update manages the updates in between revisions. It updates each field in place and determines if a change occurred. It also prevents you from leaking references into your tracked struct field types, which would be unsafe.

[nikomatsakis]

We are still working on the guidance for when to use a salsa::tracked struct versus just a plain struct (side note but I also want to add a #[salsa::untracked] to manage the derives for you and simplify your life...neither here nor there).

Some guidance

• you definitely want salsa::tracked if the thing has "identity" -- e.g., a function in your user's source code -- that you want to track from revision to revision.
• structs that just combine scalar values together don't really need to be tracked.

Right now, making things tracked comes with some runtime and memory cost, we intend to implement coarse-grained tracking that will greatly reduce that for the common case.

[carljm]

Isn't another significant reason to use a tracked struct that if you want the struct to be the parameter to a tracked function, it needs to be either an input or a tracked struct?

[nikomatsakis]

Strictly speaking tracked functions do not require a salsa struct (which can also be interned), though the current macro does require that if there is exactly 1 argument, it is a salsa struct.

[carljm]

the current macro does require that if there is exactly 1 argument, it is a salsa struct.

How deeply baked-in is this requirement?

We have a lot of tracked structs that exist not because we actually need them individually tracked as dependencies, but because we want to be able to use them as the argument to a tracked function. Ultimately this is where the desire for coarse-grained dependencies comes from.

[nikomatsakis]

Pretty baked in. The tracked data is stored on a memo of the salsa struct (it doesn't have to be tracked).

…

On Tue, Oct 1, 2024, at 2:12 PM, Carl Meyer wrote: > the current macro does require that if there is exactly 1 argument, it is a salsa struct. > How deeply baked-in is this requirement? We have a lot of tracked structs that exist not because we actually need them individually tracked as dependencies, but because we want to be able to use them as the argument to a tracked function. Ultimately this is where the desire for coarse-grained dependencies comes from. — Reply to this email directly, view it on GitHub <#576 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABF4ZXHCAONONCUH3SJJUTZZLQXLAVCNFSM6AAAAABOTWNU3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBWGY2TQNZYGA>. You are receiving this because you commented.Message ID: ***@***.***>