Prolog - cross-module asserting/retracting

Author

cross-module asserting/retracting - is this a good thing?

Brian Hulley

2005-06-09, 3:58 pm

Hi -
I'm wondering if any practical applications written in Prolog rely on
the ability to assert/retract across module boundaries. Although quite
easy to implement, allowing a module to be modified from the outside
seems to break the idea of encapsulation since the module cannot then
be analysed in isolation from the rest of the program.
However I can see that this may be useful if modules are used as
dynamic containers at runtime rather than just as a way of structuring
the static application code.

Ie as dynamic aspects of Prolog are allowed to predominate, the
environment that can be provided for a programmer in terms of analysis
etc necessarily becomes weaker, whereas if Prolog is made more "static"
by limiting assert/retract etc the programmer can be given a better
development environment.

So it seems to be a case of language power versus development
environment - what is the optimal point in this spectrum for the
programmer?

C# has the "unsafe" keyword to specify that certain code is allowed to
manipulate pointers etc.

I wonder if some set of built-in predicates could be designed and
assigned levels of safeness, so that code written with level 0
predicates would be completely amenable to static analysis whereas code
with level 3 predicates (say) would allow runtime module creation,
assert/retract, call/1 etc so that Prolog programmers could get the
best of both worlds?

Brian.

arv832

2005-06-10, 3:59 pm

I think it is useful to be able to encapsulate dynamic predicates
into a single module and then have other modules change their data.

A module which imports these dynamic predicates may manipulate them
using just assert / retract as they are local to the module.

Where the user wishes to assert/retract in a module directly
without necessarily importing the module we use
assert(fact) @ module
in IF/Prolog (see http://www.ifcomputer.de/Products/Prolog/ )

Andrew Verden

Brian Hulley

2005-06-11, 3:58 pm

arv832 wrote:
> I think it is useful to be able to encapsulate dynamic predicates
> into a single module and then have other modules change their data.
>
> A module which imports these dynamic predicates may manipulate them
> using just assert / retract as they are local to the module.

This seemed strange to me at first, ie that the head for a clause to be
asserted/retracted is looked up in the same way as the head for a goal,
since one might think importing implies right to use rather than shared
ownership. However I suppose it makes sense, and certainly follows from
the definition of assert in 8.9.2.1.c of D8, and the (IMO unfortunate)
decision of ISO to use ":" to establish a new search context instead of
for explicit resolution within the original context as in C++, C#,
Java, Haskell etc.

Another predicate such as assert_local/1 could be used to allow a
module to assert a new (hitherto locally undeclared) predicate in its
own module without fear of modifying some imported predicate, or when
it wants to override an imported predicate dynamically.

A module could protect itself from unwanted modification by declaring
itself to be closed, and mutable predicates locally_dynamic (only
modifyable from within the module itself) rather than dynamic
(modifyable from anywhere), thus solving the encapsulation problem.

(To be fair to ISO the ":"-as-search decision is probably implied by
complications arising from the desire to allow user-defined
metapredicates. If user-defined metapredicates are not allowed
everything becomes much simpler, and I think most functionality can be
achieved by using closures: instead of module M passing a term T that
needs to be compiled in the context of M while executing some
metapredicate in Module Q, why not just compile T when you are still in
module M and pass the compiled result to the user in Q as a closure? Ie
split call(Goal) into compile(Goal, Closure) and execute(Closure) so
that no meta-info is needed anywhere)

Regards, Brian.

Sponsored Links