|
|
 Up |
  |
Author: Simon StroblSimon Strobl Date: Jul 15, 2008 03:44
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
|
| |
| 19 Comments |
|
|
Author: Jan WielemakerJan Wielemaker Date: Jul 15, 2008 07:27
On 2008-07-15, 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.
|
| Show full article (1.50Kb) |
| no comments |
|
|
Author: EusebiusEusebius Date: Jul 15, 2008 07:38
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
|
| |
| no comments |
|
|
Author: Jan WielemakerJan Wielemaker Date: Jul 15, 2008 08:57
On 2008-07-15, Eusebius 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.
|
| Show full article (1.60Kb) |
| no comments |
|
|
Author: Simon StroblSimon Strobl Date: Jul 16, 2008 01:25
> 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
|
| |
| no comments |
|
|
Author: Ulrich NeumerkelUlrich Neumerkel Date: Jul 16, 2008 01:15
Eusebius polardus.org> writes:>Hi Jan,
>
>Jan Wielemaker a
|
| |
| no comments |
|
|
Author: Jan WielemakerJan Wielemaker Date: Jul 16, 2008 01:47
On 2008-07-16, 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 ...
|
| Show full article (1.37Kb) |
| no comments |
|
|
Author: Ulrich NeumerkelUlrich Neumerkel Date: Jul 16, 2008 01:29
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 ...
|
| Show full article (1.41Kb) |
| no comments |
|
|
Author: EusebiusEusebius Date: Jul 16, 2008 01:52
Jan Wielemaker a écrit :
> On 2008-07-15, Eusebius 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. ...
|
| Show full article (1.72Kb) |
| no comments |
|
|
Author: Simon StroblSimon Strobl Date: Jul 17, 2008 01:22
> 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.
|
| |
| no comments |
|
RELATED THREADS |
|
|
|
|
|
|
