Problems with SWI-Prolog?

Greetings All,

I seem to be having the problem that a clause previously asserted into
the fact base is failing when I go to retract it.  I am taking the
precaution of ensuring a match on the clause as a goal to bind the
arguments just before I do the retract.

Is anyone aware of any bugs in SWI that would explain this?

Thanx in advance,

-Mike Goodrich

Michael,

On 2005-04-05, michael.goodrich@gmail.com <michael.goodrich@gmail.com> wrote:
> Greetings All,
>
> I seem to be having the problem that a clause previously asserted into
> the fact base is failing when I go to retract it.  I am taking the
> precaution of ensuring a match on the clause as a goal to bind the
> arguments just before I do the retract.
>
> Is anyone aware of any bugs in SWI that would explain this?

No.  Nothing can be excluded however.  Without anything concrete it is
hard to say whether it is your fault or SWI-Prolog's.

Please create a little program to demonstrate the problem.  Either post
it here, send it to bugs at swi-prolog.org or file a report at the
SWI-Prolog bugzilla server.

Oh, include the version and the platform details :-)

Cheers --- Jan

Jan Wielemaker wrote:
> Michael,
>
> On 2005-04-05, michael.goodrich@gmail.com
<michael.goodrich@gmail.com> wrote: 
into 
>
> No.  Nothing can be excluded however.  Without anything concrete it
is
> hard to say whether it is your fault or SWI-Prolog's.
>
> Please create a little program to demonstrate the problem.  Either
post
> it here, send it to bugs at swi-prolog.org or file a report at the
> SWI-Prolog bugzilla server.
>
> Oh, include the version and the platform details :-)
>
> 	Cheers --- Jan



As expected, I eventually found the problem with my code, seems it was
backtracking due to the unexpected failure of a goal.  I happen to be
writing a  discrete event simulation in which all application level
goals must succeed by dealing with contingencies within said goals.

Sorry for the hysteria!

-mg

michael.goodrich@gmail.com wrote:


> backtracking due to the unexpected failure of a goal.  I happen to be
> writing a  discrete event simulation in which all application level
> goals must succeed by dealing with contingencies within said goals.

Here is something that might help you find such bugs earlier - I do
it by example:


:- op(100, fx, must_succeed).

a :-
must_succeed b,
must_succeed d.

must_succeed G :-
(G *->
true
;
writeln(did_not_succeed(G)),
fail
).

b.

d :- fail.


?- a.
did_not_succeed(d)

No


Put must_succeeds wherever you think they are due. Your code will run a litt
le
slower, but you will save some development time.
Eventually you can remove the must_succeeds in one global change, or even be
tter,
replace them by /* must_succeed */ :-)

You could also use term_expansion to roll your own determinism declarations 
and
expand goals declared deterministic to being prefixed with must_succeed. Tha
t
would be less intrusive on the code that you need to maintain.

Cheers

Bart Demoen

Bart Demoen <bmd@cs.kuleuven.ac.be> writes:

[...]

> must_succeed G :-
>          (G *->
>              true
>          ;
>              writeln(did_not_succeed(G)),
>              fail
>          ).
>

Not a criticism, but a question: You know that the goal G should
always succeed.  Why not throw an error?  Why print a warning message
instead?


--
Tom Breton, the calm-eyed visionary

Tom Breton wrote:

> Not a criticism, but a question: You know that the goal G should
> always succeed.  Why not throw an error?  Why print a warning message
> instead?

Throwing an error and making more use of it than just getting the error
message, requires more changes to the program than one might want to
invest during program development.
Just write/fail requires no other changes, and while the program
runs along, one might detect more violated must-succeeds.
And generally speaking, I do not like exceptions.
So now you know my why's ?

Can I put the question back to you ?
Why throw an error ?

Cheers

Bart Demoen

On 2005-04-08, Bart Demoen <bmd@cs.kuleuven.ac.be> wrote:
> Tom Breton wrote:
> 
>
> Throwing an error and making more use of it than just getting the error
> message, requires more changes to the program than one might want to
> invest during program development.
> Just write/fail requires no other changes, and while the program
> runs along, one might detect more violated must-succeeds.
> And generally speaking, I do not like exceptions.
> So now you know my why's ?
>
> Can I put the question back to you ?
> Why throw an error ?

Because you defined failure to be an error? You say if you print you may
get more. True, but these may be caused by this error. Most cases I do
not look any further than the first error/warning whenever I program
(except maybe a fast scan to see whether there are more surely
independent problems).

So, I like exceptions. Maybe because SWI-Prolog keeps the context ready
for the debugger if the error is not caught (that is the small
incompatibility discussed long ago). In general though, mis-used
built-ins throw exceptions and the system should thus have reasonable
tools to help and debug them. Why not exploit these?

Cheers --- Jan

Jan Wielemaker wrote:

> In general though, mis-used
> built-ins throw exceptions and the system should thus have reasonable
> tools to help and debug them. Why not exploit these?

This isn't about mis-used built-ins, is it ?

Anyway, I have defended write/fail and Jan has defended throw.
Here is something that is better than both at develop time:

must_succeed Goal :-
(Goal *->
true
;
must_succeed_menu(I,Goal)
).

must_succeed_menu(Goal) :-
writeln(did_not_succeed(Goal),
write("What do you want now ? "),
read(Answer),
exec_answer(Answer,Goal).

Now you have the option to fail or to throw or to fix the goal and continue 
..

Cheers

Bart Demoen

ps. almost immediatly after I send my first version of must_succeed, Jan sen
d
me some old code of his that does exactly what I suggested (apart from the f
ail
which he had a throw for) even with the same name (must_succeed); I start
suspecting that Jan told me about his must_succeed a long time ago.

Nice!


I should have thought of that; I am actually doing that with my own
wrapper around the 'assume' predicate.

cheers,

-mg

On 2005-04-08, Bart Demoen <bmd@cs.kuleuven.ac.be> wrote:
> Jan Wielemaker wrote:
> 
>
> This isn't about mis-used built-ins, is it ?

Not really, but what is the difference between this and a call to
functor(-,-,-)?  They are both programming errors and you need to
find (and fix) them.

> ps. almost immediatly after I send my first version of must_succeed, Jan s
end
> me some old code of his that does exactly what I suggested (apart from the
 fail
> which he had a throw for) even with the same name (must_succeed); I start
> suspecting that Jan told me about his must_succeed a long time ago.

The honour doesn't go to me and your memory isn't that bad.  I wrote
it after a user (Holger Kanwischer) has trouble realising this using
assert/retract.  The version I defined runs entirely using
term-expansion and therefore produces static code that is nicely
refreshed on a reload.

Cheers --- Jan