Remove xor as a builtin infix operator

[rotu]

xor is not an ISO infix operator

[rotu]

Would it be appropriate to add the operator declaration for xor to iso_ext.pl? Or is that inappropriate since it was deliberately omitted from ISO/IEC 13211-1:1995/Cor.2:2012 ?

[triska]

Please consider sqashing the last two commits. The comment change is not only unnecessary but as just discussed actively misleading, since it suggests a Prolog term where none is intended.

[rotu]

@triska I expect that, when I make a PR the norm is to squash-and-merge. I think that’s the GitHub default.

If you still want me to rebase instead, let me know and I will.

[rotu]

Nevermind, rebased anyway.

@mthom, I highly recommend turning on commit squashing: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests

[triska]

I would like to encourage all contributors to please make sensible PRs with commits as they are meant, and to merge them exactly as they are submitted, everything else can only end in chaos. Please note that commits can refer to each other by hashes, and squashing them destroys these references.

[rotu]

I would like to encourage all contributors to please make sensible PRs with commits as they are meant, and to merge them exactly as they are submitted, everything else can only end in chaos.

I recommend you at least experiment with GitHub squash-merges, but I'll be happy to rebase in the future.

When you squash and merge a PR it gets a message according to the PR title and description, which is sensible. Else you wind up with at least two commits per change - one for the change and one for the merge commit. For instance, the recent PR #2930 consisted of these three commits:

• ec28872
• eb96a0c
• 9dab070

Please note that commits can refer to each other by hashes, and squashing them destroys these references.

If the PR is squashed before merging, the original commit hashes get destroyed anyway, leaving the PR ID and merge commit as the only stable references. The PR review workflow in GitHub gets a little buggy and you lose per-commit CI logs (if enabled).

[triska]

Thank you a lot, this is a good change to make Scryer stricter in what it accepts!

[triska]

Thank you a lot!

[mthom]

So I should squash the commits in this PR then?

[rotu]

So I should squash the commits in this PR then?

Lol. There's only the one commit, so I'm not sure if you're ribbing me. But yes, if you do so it'll only be the one commit instead of the merge as well.

[triska]

Yes I forgot to add: a single commit can most likely be squashed without problems!

[mthom]

I don't know why but the doctest is failing. Only thing blocking me from merging this PR.

[bakaq]

Relevant: rust-lang/miri#4323

I don't think there is much to do right now, making Miri ignore doctests temporarily doesn't seem ideal. We may wait for the next nightly to rerun CI as this is already fixed upstream, or just ignore it and merge this as is, because the changes made here do not impact the engine and the doctests in any way. In fact, do we even have doctests?... We don't! This really is a non issue.

[rotu]

Agreed that this failure is not a defect from this PR. Corresponding test results in Miri: https://github.com/mthom/scryer-prolog/actions/runs/15010282834/job/42402019292#step:6:153

Doc-tests scryer_prolog

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

The miri output is also pointing out some stuff in types.rs and stack.rs that is not caused by this PR, but does seem actionable.

[bakaq]

The miri output is also pointing out some stuff in types.rs and stack.rs that is not caused by this PR, but does seem actionable.

These are warnings about provenance, I addressed most of this in #2921 in rebis-dev.

[rotu]

The miri output is also pointing out some stuff in types.rs and stack.rs that is not caused by this PR, but does seem actionable.

These are warnings about provenance, I addressed most of this in #2921 in rebis-dev.

Thank you! I'm eager to get rebis-dev merged into master.