@suss/resolution 0.20.0 → 0.21.0

package/README.md

@@ -200,6 +200,32 @@ The demand cone stays on the base facts named above. Nothing here pulls
 `reaches` or `callsInto`, so asking about a receiver does not price in
 call-graph closure.
 
+## The subject behind a registration
+
+Discovery keeps asking one question: is this receiver the app, the
+router, the thing built by calling what a library exports? Which
+`.get(...)` calls are routes and which `.use(...)` calls are mounts
+both hang on the answer, and every language feature that moves a value
+is a place the receiver can be written: a class field, a destructured
+name, a property on an object another file built. Enumerating those
+spellings in a walker loses to the language, so the question is asked
+of the rules instead.
+
+The answer comes back in two relations, both seeded by
+`wantedSubject`.
+`wantedSubjectWritten` is the written-value walk from the asked
+receiver, so the asking side can apply the single-answer policy over
+everything the receiver could be. `wantedSubjectConstruction` keeps
+only the answers that are a call or a `new`, and pairs each with where
+its callee was imported from, through however many aliases the callee
+went. The asking side checks that pair against the (module, name) a
+pack declares: exactly one distinct construction with a matching
+origin is the subject, none or several is a refusal.
+
+The construction end needs no fact of its own. Every call is already a
+`call` fact, a `new` expression included, and the join against
+`comesFrom` is what makes one of them a subject seed.
+
 ## Explaining an answer
 
 Evaluate the same rules under `@suss/datalog`'s `witnesses` algebra and

package/dist/index.cjs

@@ -1162,6 +1162,23 @@ var RESOLUTION_QUESTIONS = [
       (0, import_datalog2.lit)("callsInto", (0, import_datalog2.variable)("g"), (0, import_datalog2.variable)("m"), (0, import_datalog2.variable)("n"))
     ]
   ),
+  // Subject identity, its own demand class; the README's subject
+  // section says why the origin pair rides on the written-value walk.
+  (0, import_datalog2.rule)(
+    "wantedSubjectWritten",
+    [(0, import_datalog2.variable)("x"), (0, import_datalog2.variable)("r")],
+    [(0, import_datalog2.lit)("wantedSubject", (0, import_datalog2.variable)("x")), (0, import_datalog2.lit)("isWrittenAs", (0, import_datalog2.variable)("x"), (0, import_datalog2.variable)("r"))]
+  ),
+  (0, import_datalog2.rule)(
+    "wantedSubjectConstruction",
+    [(0, import_datalog2.variable)("x"), (0, import_datalog2.variable)("r"), (0, import_datalog2.variable)("m"), (0, import_datalog2.variable)("n")],
+    [
+      (0, import_datalog2.lit)("wantedSubject", (0, import_datalog2.variable)("x")),
+      (0, import_datalog2.lit)("isWrittenAs", (0, import_datalog2.variable)("x"), (0, import_datalog2.variable)("r")),
+      (0, import_datalog2.lit)("call", (0, import_datalog2.variable)("r"), (0, import_datalog2.variable)("c")),
+      (0, import_datalog2.lit)("comesFrom", (0, import_datalog2.variable)("c"), (0, import_datalog2.variable)("m"), (0, import_datalog2.variable)("n"))
+    ]
+  ),
   // The export table of one module, keyed by the module asked about.
   // The moduleExport rules flatten re-export chains of any length, and
   // the demand cone stays on export facts alone.

package/dist/index.js

@@ -1123,6 +1123,23 @@ var RESOLUTION_QUESTIONS = [
       lit("callsInto", v("g"), v("m"), v("n"))
     ]
   ),
+  // Subject identity, its own demand class; the README's subject
+  // section says why the origin pair rides on the written-value walk.
+  rule(
+    "wantedSubjectWritten",
+    [v("x"), v("r")],
+    [lit("wantedSubject", v("x")), lit("isWrittenAs", v("x"), v("r"))]
+  ),
+  rule(
+    "wantedSubjectConstruction",
+    [v("x"), v("r"), v("m"), v("n")],
+    [
+      lit("wantedSubject", v("x")),
+      lit("isWrittenAs", v("x"), v("r")),
+      lit("call", v("r"), v("c")),
+      lit("comesFrom", v("c"), v("m"), v("n"))
+    ]
+  ),
   // The export table of one module, keyed by the module asked about.
   // The moduleExport rules flatten re-export chains of any length, and
   // the demand cone stays on export facts alone.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@suss/resolution",
-  "version": "0.20.0",
+  "version": "0.21.0",
   "type": "module",
   "description": "Language-neutral rules for following a value to the function it comes down to.",
   "keywords": [
@@ -53,6 +53,6 @@
     "access": "public"
   },
   "dependencies": {
-    "@suss/datalog": "0.20.0"
+    "@suss/datalog": "0.21.0"
   }
 }