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.

Sign up for GitHub

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

Jump to bottom

goal_expansion/2 results depends on order of clauses #2601

Closed
hurufu opened this issue Oct 5, 2024 · 4 comments
Closed

goal_expansion/2 results depends on order of clauses #2601

hurufu opened this issue Oct 5, 2024 · 4 comments

Comments

@hurufu
Copy link
Contributor

hurufu commented Oct 5, 2024 •
edited
Loading

Inspired by #2599 (reply in thread), I tried to add a rule to warn about not defined, but used goals:

:- use_module(library(format)).

% Dummy predicate to test goal expansion. It must produce warning that append/3 is used but isn't defined.
g([], _).
g([H|T], Z) :-
    append([H], Y, Z),
    g(T, Y).

user:goal_expansion(G, _) :-
    nonvar(G),
    (   predicate_property(G, _) ->
        false
    ;   callable(G),
        prolog_load_context(module, M),
        functor(G, F, A),
        format(user_error, "% Warning: ~q not defined in ~a~n", [F/A, M])
    ),
    false.

But it doesn't work, because goal_expansion/2 must be the first clause in a file. I think it would be better without such restriction.
@triska
Copy link
Contributor

triska commented Oct 5, 2024

Any change in the logic of term_expansion/2 and goal_expansion/2 must be very carefully considered. The idea (currently) is that clauses of goal_expansion/2 only affect what comes later. For instance, library(clpz) relies on this property of goal_expansion/2, in order to convert constructs that appear in later parts of the code to constructs that are defined earlier, and not subject to goal expansion.

In the concrete case of checking for syntax errors, what do you think about creating a library with these expansions? Such a library would be included at the start of a file, and hence affect the remaining code in the file also with the current implementation.

@hurufu
Copy link
Contributor Author

hurufu commented Oct 5, 2024 •
edited
Loading

Ok, that makes sense. I think then it is better not to change goal_expansion/2 behavior.

@hurufu hurufu closed this as completed Oct 5, 2024
@triska
Copy link
Contributor

triska commented Oct 5, 2024

For semantic tests that are only applicable after a file is fully loaded, it may be worth considering to let term_expansion/2 "see" the term end_of_file at the end of consulting a file, so it has a chance to finalize everything.

@hurufu
Copy link
Contributor Author

hurufu commented Oct 5, 2024 •
edited
Loading

Yes that's good point, loader is currently implemented in such way that end_of_file isn't expanded – input stream is immediately closed as soon as reading from it returns that atom.

@hurufu hurufu mentioned this issue Oct 5, 2024
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hurufu @triska