Collection of hard to debug syntax errors

[hurufu]

Here I will collect syntax errors that are difficult to find, so if we will have an improved parser in the future it can be tested against those cases:

1. x :-
       a.
       b,
       c.

   Code can't be compiled, Scryer just reports an exception: error(permission_error(modify,static_procedure,(',')/2),load/1). no information about source location, very hard to find and can easily happen if you copy code from one predicate to another.

2. x :-
       a,
       
   y :-
       b,
       c,
       d.

   Scryer reports error at misleading place: error(syntax_error(incomplete_reduction),read_term/3:7).. After such error I usually think that the problem is in a body of y/0, but actual problem is non-terminated previous predicate.

[hurufu]

For 1st case I found a workaround – add this to your code:

:- use_module(library(format)).

user:term_expansion(G, _) :-
    nonvar(G),
    functor(G, ',', _),
    prolog_load_context(file, F),
    prolog_load_context(term_position, position_and_lines_read(_,L)),
    format(user_error, "% Warning: (~q) attempts to re-define ','/2 at line ~d of ~a~n", [G,L,F]),
    false.

And it will report a little bit of context, so it would be easier to find it:

% Warning: (b,c) attempts to re-define ','/2 at line 21 of test.pl
   error(permission_error(modify,static_procedure,(',')/2),load/1).
?- 

[hurufu]

Actually with term expansion we can already do code analysis, and print warnings if "code smell" is detected. I'll think about what else can be detected.

[triska]

One thing that may also be worth taking into account: This will truly affect all clauses that are being compiled, so it is also worth thinking about how to make this fast. For instance, if we write:

builtin((_;_)).
builtin((_,_)).
builtin((_->_)).

Then we automatically benefit from argument indexing, avoiding a linear search. In addition, you may be able to use one of the introspection predicates to detect builtin-predicates, and this could also be a good opportunity and justification to make the required lookup modes fast.

[hurufu]

Good point

builtin((_;_)).
builtin((_,_)).
builtin((_->_)).

user:term_expansion(G, X) :-
    nonvar(G),
    builtin(G),
    prolog_load_context(file, F),
    prolog_load_context(term_position, position_and_lines_read(_,L)),
    format(user_error, "% Warning: (~q) attempts to re-define ~w at line ~d of ~a~n", [G, O/2, L, F]),
    false.

[triska]

We can benefit from:

?- predicate_property((_,_), built_in).
   true.

[jjtolton]

For 1st case I found a workaround – add this to your code:

:- use_module(library(format)).

user:term_expansion(G, _) :-
    nonvar(G),
    functor(G, ',', _),
    prolog_load_context(file, F),
    prolog_load_context(term_position, position_and_lines_read(_,L)),
    format(user_error, "% Warning: (~q) attempts to re-define ','/2 at line ~d of ~a~n", [G,L,F]),
    false.

And it will report a little bit of context, so it would be easier to find it:

% Warning: (b,c) attempts to re-define ','/2 at line 21 of test.pl
   error(permission_error(modify,static_procedure,(',')/2),load/1).
?- 

this is really cool, I've been trying to figure out how to use prolog_load_context/2 for awhile, first example of it I've seen!

[hurufu]

Another one:

test(T) :-
    T == call(a->b;c).

If predicate has a lot of lines of code then this type or error is very hard to find.