very strange behaviour by Logtalk: bug?

Help requests on developing Logtalk applications

Moderator: Paulo Moura

Post Reply
joerg
Posts: 40
Joined: Fri Dec 21, 2007 9:38 am

very strange behaviour by Logtalk: bug?

Post by joerg » Fri Jun 06, 2008 2:37 pm

Hello,

let me first apologize for the length and the complicatedness of this post. I
did not know another way to solve my problem. Besides, I was not able to write
a simpler program that has the same problem.

The code given below is a method of a syntax-rule object. Its point is to
write an error message to the user, if a (user defined) clause of a syntax
rule contains a category name Category that is not defined for language
Language.

The code works except for the argument ClauseNumber. Before the not(...) part,
the value of ClauseNumber is whatever it is unified with in another
predicate. If throw(ClauseNumber) appears before not(...), Logtalk will write
1 or 2 or whatever the current clause number is.

After not(...) ClauseNumber is uninstantiated. If throw(ClauseNumber) is used after not(...),
then Logtalk will raise the following error:

ERROR: goal_thread `_G270::_G271' does not exist

I do not use threads anywhere in my program. Besides, nothing dangerous seems
to appear in swiss_knife::recursively_extends_object. (The code is given below).

What is this error message supposed to mean?

(By the way, I used Swi as Prolog compiler.)

Greetings,

Jörg


=======================================


compile_clause(Clause, _, _, ClauseNumber, _) :-
Clause = [Category, _, _],
::language(Language),
% throw(ClauseNumber),
not(
(
swiss_knife::recursively_extends_object(SyntacticCategory, syntactic_category_aka_phrase),
SyntacticCategory::language(Language),
SyntacticCategory::name(Category)
)
),
% throw(ClauseNumber),
self(Rule),
write('Error #15\n'),
write(Category),
write(' has not been defined as syntactic category for '),
write(Language),
write('.\n'),
write('In clause '),
write(ClauseNumber),
write(' of rule '),
write(Rule),
write('.'),
abort.

recursively_extends_object(Object1, Object2) :-
extends_object(Object1, Object2).

recursively_extends_object(Object1, Object2) :-
extends_object(Object1, Object3),
recursively_extends_object(Object3, Object2).

Paulo Moura
Logtalk developer
Posts: 475
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: very strange behaviour by Logtalk: bug?

Post by Paulo Moura » Fri Jun 06, 2008 3:29 pm

Hi!

The strange error message (about a non-existing "goal_thread") is generated because the Logtalk runtime (in the current stable version) does not check for non-instantiated error terms. I.e. when a throw/1 is called with a non-instantiated argument. Assuming that you're running Logtalk 2.31.6, you can apply the following patch the the "compiler/logtalk.pl" file: around line 296, add the following clauses as the first ones of the predicate '$lgt_runtime_error_handler'/1:

Code: Select all

'$lgt_runtime_error_handler'(Variable) :-
	var(Variable),
	throw(instantiation_error).

'$lgt_runtime_error_handler'(error(Variable, _)) :-
	var(Variable),
	throw(instantiation_error).

'$lgt_runtime_error_handler'(error(Variable, _, _)) :-
	var(Variable),
	throw(instantiation_error).
The next stable version will include this patch. Thanks for the bug report.

Best regards,

Paulo
Paulo Moura
Logtalk developer

joerg
Posts: 40
Joined: Fri Dec 21, 2007 9:38 am

Re: very strange behaviour by Logtalk: bug?

Post by joerg » Fri Jun 06, 2008 3:46 pm

Hi Paulo,

thank you for the code.

I am still wondering, why ClauseNumber is instantiated before the execution of the not(...) part of my code, but uninstantiated after the not(...) part of my code.

How is it possible for ClauseNumber to become uninstantiated? It isn't even used in the not(...) part.

Is this due to a Logtalk bug?


Jörg

Paulo Moura
Logtalk developer
Posts: 475
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: very strange behaviour by Logtalk: bug?

Post by Paulo Moura » Fri Jun 06, 2008 4:36 pm

joerg wrote: I am still wondering, why ClauseNumber is instantiated before the execution of the not(...) part of my code, but uninstantiated after the not(...) part of my code.

How is it possible for ClauseNumber to become uninstantiated? It isn't even used in the not(...) part.

Is this due to a Logtalk bug?
Hardly. Are you sure you're not backtracking to another clause when the not(...) call fails? Btw, use \+/1, not the not/1 predicate in order to ensure portability.

Best regards,

Paulo
Paulo Moura
Logtalk developer

joerg
Posts: 40
Joined: Fri Dec 21, 2007 9:38 am

Re: very strange behaviour by Logtalk: bug?

Post by joerg » Sat Jun 07, 2008 1:35 pm

Are you sure you're not backtracking to another clause when the not(...) call fails?
You are right. Sorry for the question. I am not yet very experienced in logic programming. Sometimes I simply forget about indeterminism. Especially after having done some work in an imperative language.

Thanks again for your hints.

Jörg

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest