Proposal - Remove Implicit Argument Sugaring from JSON Logic

[TotalTechGeek]

Background

Historically, JSON Logic has had an implicit sugaring rule that some implementations have elected to ignore, that automatically promotes a non-array argument of an operator to an array argument.

Example:
{ "+": 5 } would be tweaked to be { "+": [5] }

This offers a nice convenience to folks implementing custom operators, as it helps improve consistency and ease of development of operators (not needing to explicitly handle [5] vs 5).

This does, however, introduce limitations into the language.

By eliminating it, we could enable operators to have stricter control over the AST traversal, and enable implicit application of operators, allowing for things like:

{ "+": { "val": "arr" } }
and
{ "max": { "map": [{ "val": "arr" }, { "val": "salary" }] } }

Which otherwise would not be possible.

Proposal

Part A

I'd like to eliminate the implicit sugaring from JSON Logic; meaning that implementations will no longer be required to wrap arguments in an array before passing the input to operators.

Part B

I'd like to define two conventions we may use to define operators going forward:

"{ op: n } should produce the same result as { op: [n] }".

This convention is fairly straightforward. Most operators will follow this pattern.

Implementations may choose to promote the input to an array for convenience, or explicitly handle each type of input.

{ "+": "5" } should produce the same result as { "+": ["5"] }.

Our tests should also cover these scenarios to confirm this is enforced.

We can describe an operator as "chaining".

Operators that chain can receive their input directly from the output of another operator.

For example,

{ "+": { "val": "x" } } with the data { "x": [1,2,3] } will produce a result of 6.

This is because + will receive [1, 2, 3], which is the output of the val operation.

--

In practice, these two concepts will usually be applied at the same time.

[TotalTechGeek]

Some Slack Conversations copied over,

Aside from deciding the truthiness of empty object,
I believe the most controversial thing in the proposal will be the following check:

{
      "description": "If with non-array arguments throws",
      "rule": { "if": "apple" },
      "data": null,
      "error": { "type": "Invalid Arguments" }
}

I communicated this would be controversial because it leverages this change, to allow if to decide "I only allow array arguments"

Additionally,

@TotalTechGeek: w/ the implicit apply construct in place, I'd really like for the lazy operators to receive the raw argument / leaf passed into it
@JTeeuwissen: I think it would be best for every operator being responsible for evaluating their input. The operator defines the meaning of it's input, there is no use in evaluating it outside the context of the operator.
@TotalTechGeek: As an implementer, you can decide to implement it that way,
And a handful of implementations do,
But I think it'd be best to define a convention for the majority of operators to understand how the arguments gets interpreted.
So technically you can set it up so that all operators are "lazy",
But I can define "Hey, this is what it means when we say an operator is eager -- the arguments are received, evaluated, and then wrapped in an array if needed"
So for most operators, 5 and [5] as input would mean the same thing.
tl;dr I agree, but I'm in favor of defining a convention for "eager evaluation" that we can use to describe the majority of operators.
@JTeeuwissen: Why?
@TotalTechGeek : Because if 90% of the operators interpret the arguments the same way, it simplifies things to express "These operators follow the eager argument evaluation convention"
Only a few operators will diverge (mostly control structures like if , and, or, ??, and the comparison operators, the iterators)

[TotalTechGeek]

I am open to that; I'm actually not super opinionated on how we express it.

And I guess it is a bit different to express "This operator supports chaining" vs "This operator is eagerly traversed", as you could in theory set up an operator like + to iterate on a direct array argument and evaluate each item individually as part of the summation, while summing a chained object's array without evaluation. (And to be clear, I was never really trying to mandate implementation specifics, it was a more conceptual thing I was trying to establish, that [n] === n in most cases, and you can chain operators)

[TotalTechGeek]

My perception is that you're a +1 on Part A, and negative (can't gauge how negative, so I'll just say -1) on Part B.

If Part B was omitted, or just tweaked to explain "This is what it means when we call an operator chaining", and we explicitly defined operators with criteria that specified

• { op: n } should be the same as { op: [n] }
• It's chaining

You'd be comfortable?

[JTeeuwissen]

+1 on part A, don't feel strongly on B. Just some suggestions but I'm fine either way.

[TotalTechGeek]

But would you prefer if I tweaked part b to just establish the "chaining" convention & maybe describe the { op: n } should be the same as { op: [n] } portion, and then use those guys when specifying operators?

Over the way it's currently expressed?

In a sense, that'd still establishing a convention, but it'd be a bit looser. (I just think those two concepts will end up pretty much always going together)

[TotalTechGeek]

@JTeeuwissen I've redefined part B, and will mark you as a +0.75, (feel free to correct)

[TotalTechGeek]

@dslmeinte This guy has the biggest implications for JSON Logic.

The other guys are pretty simple (and thus will probably inspire more feedback from the community 😂)

The tl;dr is:

• No more implicit sugaring for arguments. Operators can now handle their arguments how they wish.
• Standard convention is introduced we can use to define most operators.
• The new standard convention allows for implicit application of output from operators as input to other operators, allowing for better operator chaining.
• Standard convention maintains the n === [n] construct. Allows implementers to decide how they want to handle it performance wise.
• It also enables us to be more strict with input for certain operators, like throwing if the argument is not an array.

[TotalTechGeek]

Self +1.

Current Votes

Aggregate	TC Votes in Favor	Votes
2.75	3	@TotalTechGeek (+1) @gregsdennis (+0) @JTeeuwissen (+0.75) @codetiger (+1)

Here is a link to our voting procedures.

[gregsdennis]

I'm a +0 on this. I could go either way, slightly leaning toward "vote for".

When building my implementation, I didn't understand the sugaring correctly, and as a result, I had some problems in my implementation. But this really comes down to how the feature was documented rather than the feature itself.

If there are features that disallowing sugaring enables, then that seems like a good direction to go. But it also does mean that it will break a lot of rules in the wild.

[TotalTechGeek]

@gregsdennis I actually don't think it will break backwards compatibility (in 99% of cases) since we'll define many of the core operators to explicitly handle { op: [n] } and { op: n } the same way.

Where things could break: Depending on how library authors modify their "add custom operator" method, if no compatibility mode is offered (some sort of sugaring opt-in), it could require developers to update their custom operator implementation.

[codetiger]

+1
My implementation already works as defined in proposal.

[TotalTechGeek]

I'm going to mark the proposal as "Accepted", though I'm hoping for Todd to weigh in on this one.

My rules defined (0..1] as a postive vote, but I believe the +0 in this case was meant to indicate approval, neutrality leaning positive, so I'm going to count it as a TC Vote in favor (as +0 being above 0?) 😬

[dslmeinte]

For part A: Implicit sugaring is definitely a 2-edged sword. In my opinion, only explicit sugaring can be made to really work consistently (especially over the course of the evolution of the language), by just adding another concept/construct to express the sugared variant of an already-present concept/construct. In this context, with completely and quite limited syntactic freedom, there's very little room to maneuver to be able to consistently distinguish between a desugared and implicitly-sugared utterance. In other words: eliminate implicit sugaring 👍

For part B: chaining-as-a-default is implicit sugaring. Although it would obviously be powerful to have this, there's that 2-edged sword again. So, I'm hesitant to vote either way.

[TotalTechGeek]

chaining-as-a-default

It's actually not quite a default; we will explicitly define what operators support it (which will be most of them).

The control structure operators actually will not have chaining.

I actually would like to specify that if / and / or require array arguments, and avoid the issue of chaining with them. (I'm concerned folks might implement something like or naively, and end up executing logic from context that shouldn't be)

[dslmeinte]

Ah, OK: I had understood it as the/a default. Explicitly defining what operators support it: 👍

[TotalTechGeek]

@toddbaert If available, I would like your buy-in for this.

This is a bit of a strong departure / decision; you had mentioned on Slack that you felt there was value in the chaining concept.

This is the proposal that kinda introduces it.