@suss/datalog 0.33.1 → 0.34.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -2,17 +2,17 @@
2
2
 
3
3
  Part of [suss](https://github.com/nimbuscloud-ai/suss), which reads both sides of every call in a repository and says where the two disagree.
4
4
 
5
- A small semi-naïve Datalog evaluator with stratified negation. This is
6
- the rules engine behind suss's derived program facts.
5
+ A small semi-naïve Datalog evaluator with stratified negation. suss
6
+ derives its program facts with it.
7
7
 
8
8
  ## Why suss ships a Datalog engine
9
9
 
10
- Extraction keeps running into problems that are naturally *fixpoints*:
11
- which functions are reachable from an entry point, what a bare `throw
12
- err` re-throw can actually raise (the union of everything the `try`
13
- block throws, transitively), how a wrapper of a wrapper resolves to its
14
- underlying route. Write each of those as rules over base facts and it
15
- comes to a few lines you can check by reading them:
10
+ Extraction keeps running into problems that are *fixpoints*. One is
11
+ which functions are reachable from an entry point. Another is what a
12
+ bare `throw err` re-throw can raise, which is the union of everything
13
+ the `try` block throws, transitively. A third is how a wrapper of a
14
+ wrapper resolves to its underlying route. Written as rules over base facts,
15
+ each one comes to a few lines you can check by reading them:
16
16
 
17
17
  ```ts
18
18
  import { Database, evaluate, lit, rule, variable as v } from "@suss/datalog";
@@ -34,16 +34,16 @@ evaluate(db, [
34
34
  db.facts("reachable"); // [["main"], ["helper"], ["util"]]
35
35
  ```
36
36
 
37
- Termination and soundness are the engine's job, and we prove them once.
38
- Negation (`notLit`) is *stratified*: a rule set with a negation cycle is
39
- a hard error at evaluation time, and that is what lets you check a rule
40
- on its own without thinking about the engine.
37
+ The engine guarantees termination and soundness, and those are proved
38
+ once, for the engine. Negation (`notLit`) is *stratified*: a rule set
39
+ with a negation cycle is a hard error at evaluation time. Because of
40
+ that, you can check a rule on its own without thinking about the engine.
41
41
 
42
- Because rules are plain data, with no DSL strings and no embedded code,
43
- the same rule set can later run on a faster external engine. Over the
44
- longer term, an analysis written against a set of facts (`calls`,
45
- `throws`, `handles`, and so on) does not depend on the language: a
46
- second language adapter only has to emit the same facts.
42
+ Rules are plain data, without DSL strings or embedded code, so the same
43
+ rule set can later run on a faster external engine. An analysis written
44
+ against a set of facts (`calls`, `throws`, `handles`, and so on) does
45
+ not depend on the language. A second language adapter only has to emit
46
+ the same facts.
47
47
 
48
48
  ## More
49
49