Recursive evaluation?

[rmannibucau]

Hi,

I hit an interesting case which fully depends on the implementation - some try to be more clever than others there.

High level I want to create this kind of instance {dateRange: {start, end}} with start and end coming from variables (the context/data).
The issues are:

1. dateRange is not an operator (so some impl will fail, others will see it is not in the operation registry and passthrough)
2. evaluation is not recursive so it is pretty hard to have the proper shape (vars)

Think it can be worth having some handling of these cases in the final spec.

My workarounds are to use the "clever" impl for operators (so is_logic is patch if we use the js impl as a ref) and to have a recursive kind of operation to deep evaluate the subtree but I'm not that happy with it even if it opens the doors I need.

[codetiger]

In my implementation, I've added a flag named "preserve_structure" which can be enabled when constructing the engine object. The engine preserves object structure and evaluates only valid logic throughout the data.

Please use playground and enable the check box "Preserve Structure", without it the engine throws error.
Logic:

{
  "dateRange": {
    "start": {
      "var": "startDate"
    },
    "end": {
      "var": "endDate"
    }
  }
}

Data:

{
  "startDate": "2025",
  "endDate": "2026"
}

And the result is:

{
  "dateRange": {
    "end": "2026",
    "start": "2025"
  }
}

I hope this is what you are referring to.

[rmannibucau]

yep, I called it "recursive" and I combined it with a "literal" operation which skips the evaluation otherwise you get hitten by the reversed issue, you want {var: x} and it is evaluated so both are needed

[TotalTechGeek]

Historically, I've done this three different ways,

Back in 2020 when I implemented json-logic-engine, I implemented eachKey

eachKey

{
    "eachKey": {
        "a": { "+": [1, 2] },
        "b": { "*": [3, 4] }
    }
}

Would produce
{ "a": 3, "b": 12 }

Essentially, the idea was to create an explicit operator to iterate over each key and execute its leaf node.

map

One idea is to treat an object as a functor, and use the map operator.

This doesn't quite work the same as above, but is built on the same idea; but it applies the same operation to each leaf which is a bit more restrictive.

{ "map": [{ "a": 1, "b": 2 }, { "+": [{"val": []}, 1] }] }

Would produce { "a": 2, "b": 3 }

While cute, I've rarely found use-cases for this.

obj

In quite a few of my DSL projects, I've implemented this operator, I'd argue I use this one the most. Essentially,

{
   "obj": [
        "a", {"+": [1,2] },
        "b", { "*": [3, 4]}
    ]
}

Essentially, it accepts pairs of arguments to construct an object.

[TotalTechGeek]

tl;dr

Personally I prefer to be explicit about crawling / constructing an object, and using operators like preserve to document "Hey, this is pure data; do not treat this like logic."

For my use-cases, I find it to be less ambiguous.

[rmannibucau]

The case I explained is trivial but deeply nested it becomes a mess or is not doable with some of these operators, so think evaluation speccan be specified in the ast: deep first or not for ex

[TotalTechGeek]

Hm -- I'm going to send a message here early to communicate that I'm typing up a reply to that. I've run into use-cases where deep evaluation is kind of necessary, and it's a known weakness of JSON Logic.

I want to try to find the explicit issue Jeremy discussed this in, but he noted that a weakness of JSON Logic was its difficulty embedding in larger configuration documents.

This is also why Greg kinda preferred JSON-E

[TotalTechGeek]

The way I approached this years ago was by inverting the behavior of JSON Logic / building a tool around it.

If I had deeply nested values I wanted to evaluate, I essentially just used an { "$eval": ... } or { "$logic": ... } field, and that told it "I want you to run this as JSON Logic.

I had some traversal primitive, which made it easy to construct some sort of transformer like:

const mutate = traverse(i => i?.$logic ? engine.run(i.$logic) : i)

Personally, I have a mild preference for keeping the AST relatively... rigid, and then finding a way to make it easy to invoke it.

[rmannibucau]

well i kind of just did yet another DSL cause mixing multiple was exactly the reason to avoid CEL for ex.
saying "yeah we do use X" whereas you use "X on steroid" so somebody expert in X can't use your solution was what I tried to avoid.
So yes it requires to be turing complete at some point.