This is part of the XSB integration. XSB has a general predicate declaration scheme based on the syntax
:- prop p/1, ... as prop2, prop3, ...
That is different from the Quintus tradition that has directives for each property. As a result we get rather ugly definitions such as
:- multifile p/1, q/1. :- dynamic p/1, q/1.
and similar combinations, notably involving
In general I think we should aim to minimise declarations and leave decisions to the system. Nevertheless, SWI-Prolog will inherit a few more from XSB that are practically unavoidable. One of them is
incremental that will declare networks of dynamic and tabled predicates for which the system will maintain consistency of tables under changes to the dynamic predicates. I think I would also be very happy with e.g.
:- dynamic p/1, q/1 as volatile.
I’m tempted to go with the XSB
as based annotation. A but BUT is that
as is currently an operator below the comma to support the module extensions agreed upon with YAP:
:- use_module(m, [ p/1 as mp, q/1 as mq, r/1]).
Going completely the XSB way requires to
as to be
op(1045, xfx, as). This causes syntax errors in programs that use
as in places that do not allow for high priority operators. That will also break the above, requiring to write
:- use_module(m, [ (p/1 as mp), (q/1 as mq), r/1]).
An alternative is to define these operators as
fy rather than
fx, so we get something like below. I think that is quite acceptable.
:- op(1150, fy, dynamic). :- op(1150, fy, volatile). :- dynamic volatile p/1, q/1.
The downside of this is that we must declare e.g.,
incremental as such an operator and we cannot have properties with arguments. XSB uses that for e.g.,
abstract(Level). We do not need indexing specifications, but we probably do need to the
abstract(Level) property (please forget about the why for this discussion, just assume we may need some properties with arguments).
What is your opinion on this?