You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
If we have the predicate
a _ _ is _
, the argument for not allowingis that it's not clear whether this should be implemented as
or as
...and these two implementations can have significantly different performance characteristics!
however, the check for this also eliminates
and I'd argue that that has a clear left-to-right reading in the program, though different for the inequality versus equality cases:
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.
The text was updated successfully, but these errors were encountered: