Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow functional predicates in equality and inequality statements. #87

Open
robsimmons opened this issue Dec 5, 2024 · 1 comment
Open

Comments

@robsimmons
Copy link
Owner

If we have the predicate a _ _ is _, the argument for not allowing

p :- q (a X Y).

is that it's not clear whether this should be implemented as

p :- a X Y is Z, q Z.

or as

p :- q Z, a X Y is Z.

...and these two implementations can have significantly different performance characteristics!

however, the check for this also eliminates

p :- a X Y < b X.
q :- a X Y == b X.
r :- a X Y != b X.

and I'd argue that that has a clear left-to-right reading in the program, though different for the inequality versus equality cases:

p :- a X Y is Z1, b X is Z2, Z1 != Z2.
q :- a X Y is Z, b X is Z.
r :- a X Y is Z1, b X is Z2, Z1 != Z2.

and, therefore, we should reintroduce the ability to handle functional predicates and builtins immediately around equalities and inequalities as long as they can be run with the modes that these rewritings imply.

@tausbn
Copy link

tausbn commented Dec 27, 2024

Alternatively, you could say that one interpretation is always the one that's used, and that if you want the other interpretation you have to unfold it yourself.

This would at the very least enable users to build a consistent mental model for how compound expressions get evaluated. (Whether the benefits of "more compact syntax" outweigh the drawbacks of "slightly more complicated mental model" should be considered carefully, though.)

For instance, saying that inner expressions are always put before the containing predicate/expression would give you roughly the unfoldings for <, == and != you present (where I assume it's a typo in the p case that we have Z1 != Z2 rather than Z1 < Z2).

Personally, I think it would be somewhat odd to have it supported for some predicates, but not all of them. To me, that's more complicated than both "this syntax is not allowed" and "this syntax is always unfolded in the same way".

Also, I don't know if "innermost first" is universally the most intuitive interpretation of nested expressions. It's certainly intuitive compared to most other programming languages (but logic programming languages are of course somewhat different).

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

No branches or pull requests

2 participants