Undetected data dependencies about stated HOT 3 CLOSED

Other examples for c$ that result in the same .out and .set behavior:

• $eval('a')
• b.%.a
• ($ ~> | $ | { 'a': a } |).a
• function ($it) { $it.a }($)
• ($it := $; $it.a)
• b[0 + 0]
• b.( function() { $[0] }() )
• $sift(function ($_, $key) { $key = 'a' }).a
• *[0]

from stated.

Hi spencer - Stated does not try (at present) to do semantic analysis of functions. Rather than trying to hook in, I feel the best thing to do is just this:

{
  "a": "❌",
  "b": [
    "/${a}"
  ],
  "c$": "(a;$lookup('a'))"
}

In other words, just manually add the dependency to c$. There will alway be a class of dynamic expressions. We find these to be rare. So rare in practice that they have not occurred in any real uses cases so far. But we have anticipated and the solution is pretty straightforward manual dependency setting like I showed above. Thanks!

from stated.

(Copied here from webex for completeness)

When a developer doesn't control all the code (e.g. imports), it may be difficult to reason about when a dependency needs manual declaration.

It's also not just functions that break analysis. Computed array indices (b[0 + 0]) and parent traversal (b.%.a) also currently evade analysis. (But, I would say functions are even more basic than these, since they are needed to deduplicate code.)

To clarify, my concern is about correctness, not feature richness. I think it's fine to say "we don't support X and Y". But presently, the issue is it's impossible to tell when an undetected dependency is a bug or "working as expected". I expect there to be a flood of questions as usage scales up. And if stated is to be a foundation of other user facing APIs, the problem is those APIs will receive floods of questions as well.

I'm concerned as a maintainer of those user facing APIs, that I will be pressured to adopt stated at the cost of increasing my own maintenance burden, if these correctness issues are not addressed.

from stated.