salsa/components/salsa-macros
Niko Matsakis e7d704dd8b convert DatabaseSlot to unsafe trait
The unsafe impl now asserts that the `DatabaseSlot` implementor type
is indeed `Send+Sync` if `DB::DatabaseData` is `Send+Sync`. Since our
query keys/values are a part of database-data, this means that `Slot`
must be `Send+Sync` if the key/value are `Send+Sync`. We test this
with a function that will cause compliation to fail if we accidentally
introduce an `Rc<T>` etc.
2019-07-02 06:49:24 -04:00
..
src convert DatabaseSlot to unsafe trait 2019-07-02 06:49:24 -04:00
Cargo.toml Replace volatile query type with report_untracked_read fn 2019-06-26 13:10:44 +03:00
LICENSE-APACHE rename salsa_macros to salsa-macros 2019-01-17 05:28:42 -05:00
LICENSE-MIT rename salsa_macros to salsa-macros 2019-01-17 05:28:42 -05:00
README.md rename salsa_macros to salsa-macros 2019-01-17 05:28:42 -05:00

salsa

Build Status Released API docs Crates.io

A generic framework for on-demand, incrementalized computation.

Obligatory warning

Very much a WORK IN PROGRESS at this point. Ready for experimental use but expect frequent breaking changes.

Credits

This system is heavily inspired by adapton, glimmer, and rustc's query system. So credit goes to Eduard-Mihai Burtescu, Matthew Hammer, Yehuda Katz, and Michael Woerister.

Key idea

The key idea of salsa is that you define your program as a set of queries. Every query is used like function K -> V that maps from some key of type K to a value of type V. Queries come in two basic varieties:

  • Inputs: the base inputs to your system. You can change these whenever you like.
  • Functions: pure functions (no side effects) that transform your inputs into other values. The results of queries is memoized to avoid recomputing them a lot. When you make changes to the inputs, we'll figure out (fairly intelligently) when we can re-use these memoized values and when we have to recompute them.

How to use Salsa in three easy steps

Using salsa is as easy as 1, 2, 3...

  1. Define one or more query groups that contain the inputs and queries you will need. We'll start with one such group, but later on you can use more than one to break up your system into components (or spread your code across crates).
  2. Define the query functions where appropriate.
  3. Define the database, which contains the storage for all the inputs/queries you will be using. The query struct will contain the storage for all of the inputs/queries and may also contain anything else that your code needs (e.g., configuration data).

To see an example of this in action, check out the hello_world example, which has a number of comments explaining how things work.

Videos about Salsa

There are also two videos explaining how Salsa works:

  • How Salsa Works, which gives a high-level introduction to the key concepts involved and shows how to use salsa;
  • Salsa In More Depth, which really digs into the incremental algorithm and explains -- at a high-level -- how Salsa is implemented.

Getting in touch

The bulk of the discussion happens in the issues and pull requests, but we have a zulip chat as well.