Skip to content

Conversation

@saoirse-a
Copy link
Contributor

Includes additional details about the various operators (such as their Datalog syntax) in the specification.

Includes additional details about the various operators (such as their
Datalog syntax) in the specification.
Copy link
Contributor

@divarvel divarvel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added comments for small inconsistencies and questions. LGTM otherwise.

I don't remember if the spec lists associativity and precedence (I'm on my phone), but it it doesn't it would be a good addition

- **HeterogeneousEqual:** Returns whether the operands are equal; returns false if the operands have
different types
- **HeterogeneousNotEqual:** Returns whether the operands are not equal; returns false if the
operands have different types
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be "returns true if operands have different types?"

different types
- **HeterogeneousNotEqual:** Returns whether the operands are not equal; returns false if the
operands have different types
- **Contains:** For strings, returns whether the righ toperand is a substring of the left operand.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **Contains:** For strings, returns whether the righ toperand is a substring of the left operand.
- **Contains:** For strings, returns whether the right operand is a substring of the left operand.

operands have different types
- **Contains:** For strings, returns whether the righ toperand is a substring of the left operand.
For sets, arrays, and maps, returns whether the right operand is an element of the left operand;
if the right and left operands are both sets, returns whether the right operand is a a subset of
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd move this one above the preceding since the one above is more general than this one

- **Mul:** Multiplies the operands together. _(see overflow)_
- **Div:** Divides the left operand by the right operand. _(see overflow)_
- **And:** Returns whether both operands are true. _(see overflow)_
- **Or:** Returns whether either operand is true. _(see overflow)_
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is eager or susceptible to overflow?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, but my adding notes to the list of operators is (meant to apply only to the arithmetic operators and overflowed into the boolean operators)

- **Get:** Returns the value under that key (for arrays, the integer index into the array; for maps,
the key in the map).
- **TryOr:** Evaluates the left operand; if it evaluates without error, returns the value it
evaluates to. If it throws any error, swallows that error and evaluates to the right operand.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: if the right operand throws an error, it will always result in an error, even if the left operand evaluates successfully


##### FFI

FFI calls are implementation defined. Each carry a function name which is mapped to a user-defined
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe this needs a clear warning that users must make sure that all implementations work exactly in the same way. This seems obvious, but has been the source of a lot of policy engine issues, especially when used across different languages

@Geal
Copy link
Contributor

Geal commented Jan 8, 2026

@saoirse-a thank you for clarifying the spec there, it helps a lot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants