Using consult in a directive to load source code; it puzzles me?

Help!
1

In the EDCG package (src) are the directives to load dependent source code files

:- ['acc-pass.pl'].
:- ['special-util.pl'].
:- ['generic-util.pl'].

Normally I would expect the code to be either in the same source code file or loaded using use_module.

Since the code is loaded this way my editor (VSC) with plug-in (VSC-Prolog) is flagging many of the predicates as not recognized. This is more of an annoyance than a concern for now.

I am trying to reason why the code was loaded like this; is it something I should learn about or something that I can just know exist and move on without worries?

2

Coding style guideline:
Never ever use top-level interpreter shortcuts in source files.

P.S. I know that you are not the author of that package. In that particular case, the include/1 directive should have been used.

1 Like
3

So changing

:- ['acc-pass.pl'].
:- ['special-util.pl'].
:- ['generic-util.pl'].

to

:- include('acc-pass.pl').
:- include('special-util.pl').
:- include('generic-util.pl').

fixed all the warning messages and the code loads and works.

EDIT

Since some of the files had redundant include commands, refactored them all into the first file as

:- include('messages.pl').
:- include('generic-util.pl').
:- include('special-util.pl').
:- include('acc-pass.pl').

and commented out the includes in the included files. The code still loads and works, but the editor is now showing some not defined predicate warnings, but not as many as before. Since the code is small I will just leave all the includes in the included files active and not be concerned that the predicates are being overwritten a few times. :slightly_smiling_face:

Thanks Paulo.

4

Looked into the source files. The include/1 directives are only required in the main source file, edcg.pl. The VSC plug-in is likely looking into each file in isolation, hence the warnings. This is plug-in issue, not a Prolog issue.

1 Like
5

Totally agree. :slightly_smiling_face:

6

The clean solution is probably to turn the utilities into their own module and use use_module/1,2. IMO include has very little reason to exist. In some cases you can use it to share e.g., multifile declarations.

1 Like
7

Hmmm … that package has been “archived” in github and hence can’t be modified. (The original code was written ~30 years ago, so no surprise that it doesn’t use modules.)

I don’t mind updating the code to use modules; what’s the best way of handling this situation? Presumably, I’d clone the code into my github repository and update it; but can I replace the SWI-Prolog “pack”?

1 Like
8

The code already uses a module, edcg. The code in the other files is not useful on their own. This makes the include/1 solution preferable to converting those other files into modules and then use use_module/1-2 directives. If you look into e.g. the acc-pass.pl file, there’s no point in having it as a module as the exports are only meaningful for the edcg module. Same for the other files (except edcg.pl, of course).

1 Like
9

I have to agree with Paulo on this one. As I see it there really only needs to be one source code file and one module.

10

Agreed – the total line count is only 319, which is small enough for a single file.

So, if I copy this to my own github repository, I presume I can replace the existing “pack”? Are there any downsides from me taking ownership? (I’ll send a message to the current owner, to tell him what I’m doing; and will acknowledge his work, of course.)

2 Likes
11

I need to change the location. Just send me the new location when ready.

12

It is your call, but when I first started using this the use of the library(tap) seemed a bit dated.

If you are updating the tests, please also consider completing the test using castor and pollux or removing them. I only figured out what they meant by reading about them somewhere, and I can not even find that somewhere again. :thinking:

EDIT

My test for castor and pollux

Click triangle to reveal test 
% NB Example from https://www.swi-prolog.org/pack/file_details/edcg/t/examples.pl is not complete
% Complete example exits in https://www2.eecs.berkeley.edu/Pubs/TechRpts/1990/CSD-90-583.pdf

% Declare accumulators
edcg:acc_info(castor,_,_,_,true).

% Declare passed arguments
edcg:pass_info(pollux).

% Declare predicates using these hidden arguments
edcg:pred_info(p,1,[castor,pollux]).  % 1 - X
edcg:pred_info(q,1,[castor,pollux]).  % 1 - Y
edcg:pred_info(r,1,[castor,pollux]).  % 1 - Y

% The program
p(X) -->>
    Y is X + 1,
    q(Y),
    r(Y).

q(Y,_,_,P) :-
    format('q - Y: ~w, P: ~w~n',[Y,P]).
r(Y,_,_,P) :-
    format('r - Y: ~w, P: ~w~n',[Y,P]).

% ?- listing(p).
% p(X, A, B, C) :-
%     Y is X+1,
%     q(Y, A, D, C),
%     r(Y, D, B, C).

% Variables names changed for clarity
%
% p(X, Castor_1, Castor_3, Pollux) :-
%     Y is X+1,
%     q(Y, Castor_1, Castor_2, Pollux),
%     r(Y, Castor_2, Castor_3, Pollux).

% -------------------------------------

:- begin_tests(p).

test(p) :-
    with_output_to(string(Output),p(1,a,a,c)),

    assertion( Output == "q - Y: 2, P: c\nr - Y: 2, P: c\n" ).

:- end_tests(p).
1 Like
13

I assume that the VSC Prolog plug-in you mentioned is the one wrote by @ArthurWang? He also wrote a nice VSC Logtalk plug-in that is affected by a similar issue. The solution could be, in both cases, to have the plug-in calling the make tools if a file in a project is modified. This, of course, implies that the code was loaded at least once and that the Prolog process is kept alive. If that can be done, it would help if there is some plug-in interface to select a file in the project as the project loader file (assuming such a file exists; but that’s often the case).

1 Like
14

That drove my attention that I was also missing a test for that example in the Logtalk port of EDCGs. Added as:

test(gemini_1) :-
	gemini::p(1, S0, S, _),
	S0 == S.
1 Like
15

Please file missing test cases, bugs, etc. for pack(edcg) against https://github.com/kamahen/edcg
(assuming that I’ll take it over and update the pack accordingly)

16

I’ve taken over maintenance of EDCG and have added issues for updating the tests.

1 Like
17

Does making the code work with library plunit imply that the code would be modified to be work with modules, or should that be another issue?

18

Yes, I should make EDCG work better with modules. You might want to open an issue about that as well. (It’ll probably be a little while before I get to it, though …).

19

I wasn’t expecting you to make the changes.

I plan to give it a try myself but suspect I will do it wrong, post to seek feedback, nicely be shown my mistakes, learn and then rinse and repeat.

The primary reason I see for adding it as an issue is so that those who try to use EDCG with modules and fail will know that it was not their fault but an issue with the code. :slightly_smiling_face:

20

I just reinstalled the pack and I got release 0.9.0.2, but looking at github the release is 0.9.2.

I noticed you updated the download link, my guess is that Jan would have to manually update the download link also due to the security measures?