meta_predicate is unexpectedly an operator

[triska]

We currently have:

?- current_op(Pri, Fix, meta_predicate).
   Pre = 1199, Fix = fx, unexpected.

meta_predicate is not a standard operator, and therefore should not be defined as an operator!

I would greatly appreciate any help with this: First, systematically remove all occurrences in library code where meta_predicate is used as a prefix operator (use functional notation instead in such cases), and second, remove the operator definition to make Scryer more strictly conforming in its default execution mode, i.e., on startup.

[hurufu]

Doesn't it conflict with the requirement to accept a sequence of meta-predicate specifications (#2444 and similar to #1586)? IMHO sequences only make sense if meta_predicate is used as an operator. Like in the following example:

:- meta_predicate a(0), b(1), c(2).

Otherwise they don't help with readability.

[UWN]

Doesn't it conflict with ... similar to #1586)?

No. In #1586 all examples use functional notation for the directives.

[hurufu]

I agree, but from the readability and developer experience point of view, I don't see benefit of meta_predicate((a(0), b(1), c(1))) notation compared to let's say meta_predicate([a(0), b(1), c(2)]). If it is just standards compliance issue, then I'm only for it.

[triska]

let's say meta_predicate([a(0), b(1), c(2)])

Yes, a predicate indicator list should work, as for dynamic/1. I have filed #2823 for this, thank you a lot!

If it is just standards compliance issue, then I'm only for it.

Yes perfect! Everyone who wants more dedicated operators can define them in ~/.scryerrc or in applications. A great advantage of defining only the standard operators by default is that we can then readily use Scryer Prolog as a reference system to test whether other conforming systems will also be able to parse the code as it is.