canonical alternative to assert and retract

Hello,

is there something like a canonical alternative to assert and retract?
In other words, are there algorithms for translating any Prolog
program that uses assert and retract into an equivalent program that
does without these predicates? And, if so, will the "compiled" (i.e.
the static) programs be, in general, equally or more or less
efficient? Do you know good articles about this issue?

Apart from aesthetical aspects, an obvious advantage of avoiding
assert and retract would be that one's programs are compatible with
more compilers. Thus, one could have Mercury or Yield Prolog compile
one's code.

The Mercury documentation is quite abstract about how to avoid assert
and retract: "The use of assert and retract should be replaced with a
collection data structure threaded through the relevant part of the
program."

Simon

On 2008-07-15, Simon Strobl <Simon.Strobl@gmail.com> wrote:
> Hello,
>
> is there something like a canonical alternative to assert and retract?
> In other words, are there algorithms for translating any Prolog
> program that uses assert and retract into an equivalent program that
> does without these predicates? And, if so, will the "compiled" (i.e.
> the static) programs be, in general, equally or more or less
> efficient? Do you know good articles about this issue?

Considering that assert/retract are destructive operations
(i.e. survive backtracking) and using Prolog datastructures is subject
to backtracking, it will get very hard to convert the one
automatically into the other.

> Apart from aesthetical aspects, an obvious advantage of avoiding
> assert and retract would be that one's programs are compatible with
> more compilers. Thus, one could have Mercury or Yield Prolog compile
> one's code.

Its not just about aesthetics. Its also about global namespaces,
cleanup and consistency under backtracking. Assert/retract should
be banned from Prolog teaching, possibly except for issues such as
program transformation or importing semi-static external data into
a Prolog program.

> The Mercury documentation is quite abstract about how to avoid assert
> and retract: "The use of assert and retract should be replaced with a
> collection data structure threaded through the relevant part of the
> program."

It will be hard to say anything more concrete, I fear.

Cheers --- Jan

Hi Jan,

Jan Wielemaker a écrit :
> Assert/retract should
> be banned from Prolog teaching, possibly except for issues such as
> program transformation or importing semi-static external data into
> a Prolog program.

It's probably not very related to the original question, but I'm
interested in your remark. What would you use instead of assert/retract,
in order to simulate the learning of a new fact, say in an agent's
belief set?
I'd like to have your opinion on what should be used instead of assert
when it is possible.

Regards,
Eusebius

On 2008-07-15, Eusebius <eusebius_nntp@polardus.org> wrote:
> Hi Jan,
>
> Jan Wielemaker a �crit :
>> Assert/retract should
>> be banned from Prolog teaching, possibly except for issues such as
>> program transformation or importing semi-static external data into
>> a Prolog program.
>
> It's probably not very related to the original question, but I'm
> interested in your remark. What would you use instead of assert/retract,
> in order to simulate the learning of a new fact, say in an agent's
> belief set?
> I'd like to have your opinion on what should be used instead of assert
> when it is possible.

It is definitely possible to represent the agents beliefs in a binary
tree (i.e. library(assoc) or library(rbtrees)). In some cases you may
wish to represent the beliefs as a purely logical Prolog program, but
often you don't get very far as soon as recursion comes into play.
Anyway, if you do so, assert/retract may be appropriate. Also note that
assert/retract maintain a representation of a changing world, which
could justify the use of its destructive nature. When storing data for
reasoning about a constant environment (snapshot), the backtracking
nature of datastructures is much more appropriate.

There is rarely an absolute one and only answer, but in practise I see
far too much assert/retract. Things are improving a current project
that uses a lot of multi-threading. People are aware that simple
assert/retract will cause problems and prefer datastructures over
making the assert/retract code thread-safe :-) I.e. it must be made
more complicated :-)

Cheers --- Jan

Eusebius <eusebius_nntp@polardus.org> writes:
>Hi Jan,
>
>Jan Wielemaker a écrit :
>> Assert/retract should
>> be banned from Prolog teaching, possibly except for issues such as
>> program transformation or importing semi-static external data into
>> a Prolog program.
>
>It's probably not very related to the original question, but I'm
>interested in your remark. What would you use instead of assert/retract,
>in order to simulate the learning of a new fact, say in an agent's
>belief set?

When an agent's state is represented by pairs of states before/after,
you can reason about alternative outcomes simultaneously. You can use
Prolog as a query language about the behaviour of an agent acting in
different worlds. You will be able to answer question like:

What must happen that an agent does something? Can this happen at all?

What must happen that an agent change/does not change its beliefs?

Is it possible that an agent changes its beliefs and then reconsiders
it?

In general such questions are about infinitely many possibilities. A
reduction to finite ones is inevitable. But even with this restriction,
this approach will produce much more coverage than single stepping
through of a single thread of one single world. It might help you to
discover interesting properties and is very useful for testing.

> It will be hard to say anything more concrete, I fear.

O.k. Maybe I should have asked for a subset of the possible usages of
assert/retract.

A program of mine comes in two versions. Both versions do the same
thing. The difference is that version 1 does not use assert/retract
while version 2 does. In the vast majority of cases, version 2 is much
faster.

Both versions take as input a sentence and give as output a set of
parses. Version 1 simply tries all grammar rules to parse the
sentence. When there are many rules, this may take quite a long time.
Version 2 first uses the set of tokens the sentence consists of to
determine which rules may be relevant, asserts those rules, parses the
sentence and then retracts the rules.

Using standard parsing techniques is not an option for me because my
rules differ from standard rules and I want to be able to add more and
uncommon features to them in the future.

How could version 2 be made static?

Simon

Simon Strobl <Simon.Strobl@gmail.com> writes:
>> It will be hard to say anything more concrete, I fear.
>
>O.k. Maybe I should have asked for a subset of the possible usages of
>assert/retract.
>
>A program of mine comes in two versions. Both versions do the same
>thing. The difference is that version 1 does not use assert/retract
>while version 2 does. In the vast majority of cases, version 2 is much
>faster.
>
>Both versions take as input a sentence and give as output a set of
>parses. Version 1 simply tries all grammar rules to parse the
>sentence. When there are many rules, this may take quite a long time.
>Version 2 first uses the set of tokens the sentence consists of to
>determine which rules may be relevant, asserts those rules, parses the
>sentence and then retracts the rules.
>
>Using standard parsing techniques is not an option for me because my
>rules differ from standard rules and I want to be able to add more and
>uncommon features to them in the future.
>
>How could version 2 be made static?

You can parameterize your rules with a further argument containing
a vector as a structure with an argument for each rule.
An argument 1 meaning, that rule is used, and 0 otherwise.

r(..., V) :- arg(23,V,1), ...

You might also use such a scheme in the other direction (provided your
programs are monotonic) by leaving the vector's arguments free.
This tells you what rules are required.

On 2008-07-16, Simon Strobl <Simon.Strobl@gmail.com> wrote:
>> It will be hard to say anything more concrete, I fear.
>
> O.k. Maybe I should have asked for a subset of the possible usages of
> assert/retract.
>
> A program of mine comes in two versions. Both versions do the same
> thing. The difference is that version 1 does not use assert/retract
> while version 2 does. In the vast majority of cases, version 2 is much
> faster.
>
> Both versions take as input a sentence and give as output a set of
> parses. Version 1 simply tries all grammar rules to parse the
> sentence. When there are many rules, this may take quite a long time.
> Version 2 first uses the set of tokens the sentence consists of to
> determine which rules may be relevant, asserts those rules, parses the
> sentence and then retracts the rules.
>
> Using standard parsing techniques is not an option for me because my
> rules differ from standard rules and I want to be able to add more and
> uncommon features to them in the future.
>
> How could version 2 be made static?

If compatibility is not an issue, I would not bother. If that is the
reason, I guess your rules need some quick selector at the start to
see which one could be applicable. I can imagine something along these
lines can be implemented, but it is mostly likely more complicated than
what you do now.

Cheers --- Jan

Jan Wielemaker a écrit :
> On 2008-07-15, Eusebius <eusebius_nntp@polardus.org> wrote:
>> Hi Jan,
>>
>> Jan Wielemaker a �crit :
>>> Assert/retract should
>>> be banned from Prolog teaching, possibly except for issues such as
>>> program transformation or importing semi-static external data into
>>> a Prolog program.
>> It's probably not very related to the original question, but I'm
>> interested in your remark. What would you use instead of assert/retract,
>> in order to simulate the learning of a new fact, say in an agent's
>> belief set?
>> I'd like to have your opinion on what should be used instead of assert
>> when it is possible.
>
> It is definitely possible to represent the agents beliefs in a binary
> tree (i.e. library(assoc) or library(rbtrees)). In some cases you may
> wish to represent the beliefs as a purely logical Prolog program, but
> often you don't get very far as soon as recursion comes into play.
> Anyway, if you do so, assert/retract may be appropriate. Also note that
> assert/retract maintain a representation of a changing world, which
> could justify the use of its destructive nature. When storing data for
> reasoning about a constant environment (snapshot), the backtracking
> nature of datastructures is much more appropriate.
>
> There is rarely an absolute one and only answer, but in practise I see
> far too much assert/retract. Things are improving a current project
> that uses a lot of multi-threading. People are aware that simple
> assert/retract will cause problems and prefer datastructures over
> making the assert/retract code thread-safe :-) I.e. it must be made
> more complicated :-)
>
> Cheers --- Jan

Thanks for the hints!
Regards,
Eusebius

> You can parameterize your rules with a further argument containing
> a vector as a structure with an argument for each rule.
> An argument 1 meaning, that rule is used, and 0 otherwise.
>
> r(..., V) :- arg(23,V,1), ...

Thanks for the hint. I already considered to use a solution of this
type. The problem is that I have no idea how the vectors should look
like.