Prolog - Problems with SWI-Prolog?

Author

Problems with SWI-Prolog?

michael.goodrich@gmail.com

2005-04-06, 12:44 pm

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

Jan Wielemaker

2005-04-06, 12:44 pm

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

michael.goodrich@gmail.com

2005-04-07, 4:00 pm

Jan Wielemaker wrote:
> Michael,
>
> On 2005-04-05, michael.goodrich@gmail.com
<michael.goodrich@gmail.com> wrote:
into[color=darkred]
>
> 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

Bart Demoen

2005-04-07, 4:00 pm

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 little
slower, but you will save some development time.
Eventually you can remove the must_succeeds in one global change, or even better,
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. That
would be less intrusive on the code that you need to maintain.

Cheers

Bart Demoen

Tom Breton

2005-04-08, 3:58 am

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

Bart Demoen

2005-04-08, 8:58 am

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

Jan Wielemaker

2005-04-08, 8:58 am

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

Bart Demoen

2005-04-08, 4:00 pm

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 send
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.

michael.goodrich@gmail.com

2005-04-08, 4:00 pm

Nice!

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

cheers,

-mg

Jan Wielemaker

2005-04-08, 4:00 pm

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 send
> 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

Tom Breton

2005-04-08, 8:58 pm

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

> 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.

You could catch it and handle it too, but all you really need to do is
to throw it.

Anyways, no handler is going to fix a broken design assumption, so
catching it as a specific case doesn't make sense.

> Just write/fail requires no other changes, and while the program
> runs along, one might detect more violated must-succeeds.

It's true that more must-succeeds will probably trigger, but IMO this
is not an advantage. Further faults are usually either repititions of
the same fault or are indirectly caused by it. Generally speaking,
they tell you little. I find it's far more effective to focus on
fixing the first problem.

> 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 know (or maybe falsely believe) that goal G should always
succeed. If that's wrong, the assumption needs fixing. ISTM a
warning message is insufficient.

Secondly, throwing an error lets you take advantage of debugging
functionality, for instance seeing the call stack.

Thridly, because once the execution passes the point of the error (or
warning), there's nothing to be gained by letting it continue to run.
The part(s) that you need to fix has already executed, either just now
or earlier.

And fourthly, because a failed design assumption really is an error,
not a condition to be warned of. There's something to be said for
conceptual precision.

--
Tom Breton, the calm-eyed visionary

Bart Demoen

2005-04-08, 8:58 pm

Tom Breton wrote:

> It's true that more must-succeeds will probably trigger, but IMO this
> is not an advantage. Further faults are usually either repititions of
> the same fault or are indirectly caused by it. Generally speaking,
> they tell you little.

Jan said the same thing.
How about having a compiler that on the first syntax error in your
program just tells you about that error, and lets you fix it ... so that
you need another compile for detecting the second syntax error and so
on. I doubt you would like that.
But for a must_succeed error, that's the only good approach ?
Why ?

Cheers

Bart Demoen

Bart Demoen

2005-04-08, 8:58 pm

Tom Breton wrote:

> And fourthly, because a failed design assumption really is an error,
> not a condition to be warned of. There's something to be said for
> conceptual precision.
>

Conceptual precision is not at stake: I never said anything about
"warning". A unexpected visible message during development time is as
much an error as an exception throwing event. It's all interpretation
of what happens: the things themselves carry no semantics.

Cheers

Bart Demoen

Jan Wielemaker

2005-04-09, 8:57 am

On 2005-04-08, Bart Demoen <bmd@cs.kuleuven.ac.be> wrote:
> Tom Breton wrote:
>
>
> Jan said the same thing.
> How about having a compiler that on the first syntax error in your
> program just tells you about that error, and lets you fix it ... so that
> you need another compile for detecting the second syntax error and so
> on. I doubt you would like that.
> But for a must_succeed error, that's the only good approach ?
> Why ?

Because Prolog in general reports only 1 syntax error per clause (term).
and (disregarding operator declarations), the terms are independent. So,
the reported errors are normally all errors on their own. Most C compilers
do not work that way and they make me fix the first error and do a quick
scan for ones that are most likely unrelated. I do not bother too much for
errors close after the first, as they are often just caused by it.

Cheers --- Jan

C. M. Sperberg-McQueen

2005-04-14, 3:58 am

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

> How about having a compiler that on the first syntax error in your
> program just tells you about that error, and lets you fix it ... so that
> you need another compile for detecting the second syntax error and so
> on. I doubt you would like that.

Well, actually, many people did like Turbo Pascal
when it first came out. I never heard anyone
complain about its stop-on-first-error behavior.

Perhaps since Turbo Prolog v2 was the first compiler I
ever used, I personally have been slightly mystified
ever since by compilers which insist on doing things
differently. If their error recovery were better,
I might not mind. But it's so often worthless.

(This is not to take sides over how best to
write must_succeed.)

-C. M. Sperberg-McQueen
World Wide Web Consortium

Sponsored Links