The code snippets shown on the page are
almost valid Prolog syntax. The only issues that prevent them from being actual Prolog syntax are, as far as I can tell, very minor syntactic issues. For example, != cannot be defined as an infix operator in Prolog because ! is a so-called
solo char and therefore != is not admissible as a single token in Prolog. The obvious fix for this concrete issue is to replace every occurrence of != in these snippets with the well-known Prolog predicate dif/2 which holds if and only if its two arguments are
different.
For instance, the first example from the page:
projects_with_vulnerable_log4j(P) :-
projects(P),
contains_jar(P, "log4j", Version),
Version != "2.17.1",
Version != "2.12.4",
Version != "2.3.2".
would become:
projects_with_vulnerable_log4j(P) :-
projects(P),
contains_jar(P, "log4j", Version),
dif(Version, "2.17.1"),
dif(Version, "2.12.4"),
dif(Version, "2.3.2").
or, shorter and equivalently, by using full Prolog including higher-order predicates such as maplist/2:
projects_with_vulnerable_log4j(P) :-
projects(P),
contains_jar(P, "log4j", Version),
maplist(dif(Version), ["2.17.1","2.12.4","2.3.2"]).
This third version could of course be generated
automatically from the snippet above. We could also define dif or many other tokens as infix operators, so that we can use operator notation as in the original snippet, all while keeping to standard Prolog syntax.
Analogously for |> and the let-bindings that occur in the sample snippets: Chances are that they can be expressed somehow also with standard Prolog syntax with suitable operator definitions, or with small conforming extensions if absolutely required.
The third example in the README is already perfectly valid Prolog code, and can be parsed and interpreted with every conforming Prolog system:
contains_jar(P, Name, Version) :-
contains_jar_directly(P, Name, Version).
contains_jar(P, Name, Version) :-
project_depends(P, Q),
contains_jar(Q, Name, Version).
The main issue here is: This "own Datalog" is extremely close to Prolog syntax, much closer to Prolog than any other Datalog "variant" I have so far seen on HN. The question therefore is: Why not go the small extra step and just use standard Prolog syntax? One advantage of this is that such programs could then be read and reasoned about directly (i.e., without requiring any manual parsing) with every conforming Prolog system. Another advantage is that such programs would also automatically benefit from all improvements in Prolog engines, either via meta-interpretation or by virtue of being valid Prolog
programs too. For instance, the first snippet shown in the README, with the small syntactic change I outlined, is already a valid Prolog program and can be run with SICStus Prolog etc.
Using Prolog syntax does not mean that that the programs have to be interpreted in the same way as Prolog would by default. It is also possible to syntactically include constructs that cannot be directly interpreted in Prolog, but require a custom interpreter. The point about syntactic compatibility stands regardless.