Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate code from SWI-Prolog version 7.x to 8.x #117

Closed
jnidzwetzki opened this issue Jul 30, 2022 · 2 comments
Closed

Migrate code from SWI-Prolog version 7.x to 8.x #117

jnidzwetzki opened this issue Jul 30, 2022 · 2 comments

Comments

@jnidzwetzki
Copy link

Hello,

For several years, we have been using SWI-Prolog in the query optimizer of our database. At the moment, SWI-Prolog 7.6 is used in the project, but we are trying to migrate to a newer version. However, I have observed one issue with the new SWI-Prolog version, and I want to ask if this issue is known and if there are any known solutions or ideas on how to address the problem.

SWI-Prolog highlights matching brackets by moving the cursor to the opening bracket for a short time when a closing bracket is entered. This works fine after swipl 7 or 8 are started. After our code is loaded, the functionality works in swipl 7. In swipl 8 the error message ERROR: /usr/lib/swi-prolog/library/lists.pl:48:16: Syntax error: Operator expected [...] (see the test code below for the full error message) is shown when the closing bracket is entered.

Since we are processing SQL with our Prolog program, operators such as delete are defined (e.g., op(993, fx, delete)). So far, this has not caused any problems. In SWI-Prolog 8.x, we seem to face a name conflict with this definition. I have created a simple program that demonstrates the change in Prolog's behavior.

A workaround is to start swipl with the option --tty=false, but this also disables the history.

Simple Test Code

$ cat test.pl

delete() :- print('Hello World').
:- op(993, fx, delete).

SWI-Prolog 7.x

$ swipl
Welcome to SWI-Prolog (threaded, 64 bits, version 7.6.4)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.

For online help and background, visit http://www.swi-prolog.org/
For built-in help, use ?- help(Topic). or ?- apropos(Word).

?- consult(test).
true.

# Bracket pairs are highlighted as expected
?- ()

SWI-Prolog 8.x

$swipl
Welcome to SWI-Prolog (threaded, 64 bits, version 8.4.2)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.

For online help and background, visit https://www.swi-prolog.org/
For built-in help, use ?- help(Topic). or ?- apropos(Word).

?- consult(test).
true.

### Error occurs after typing the closing bracket
?- (ERROR: /usr/lib/swi-prolog/library/lists.pl:48:16: Syntax error: Operator expected
ERROR: /usr/lib/swi-prolog/library/lists.pl:81:
ERROR:    Domain error: `module_header' expected, found `:-autoload(library(error),[must_be/2])’

Line 48 of /usr/lib/swi-prolog/library/lists.pl is

delete/3,                     % ?List, ?X, ?Rest

Is there any way to run the code with SWI-Prolog 8.x without making major changes (e.g., introducing namespaces)?

Best Regards
Jan

@JanWielemaker
Copy link
Member

I see. This is because the autoloader reads the library module header using operators from user. It works by switching off autoloading (but that requires importing everything explicitly). I have pushed SWI-Prolog/swipl-devel@8a47fcb to use the system operator table.

It is not likely there will be another 8.4.x release, so you can either apply this patch on 8.4 or use 8.5 (or one of the other work-arounds).

@jnidzwetzki
Copy link
Author

Hello @JanWielemaker,

Thank you so much for your quick reply, the patch, and the explanation. I added a set_prolog_flag(autoload, user). call to our Prolog code; this also solves the problem. Our code now runs on the existing 8.x versions of SWI-Prolog.

Thanks again for your help
Jan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants