Unexpected compile time error with unbound goals in DCG expansion

Discussion
1

Hey,
I’ve stumbled upon an unexpected compile time error that I’ve tracked down to what seems to be an edge case issue in DCG expansion.
To reproduce, load the following lines in SWI-Prolog:

% Works as expected: no warnings
good_dcg_bound_meta_call --> { Goal = true, Goal }. 
% Works as expected: Singleton variables: [Goal]
good_dcg_unbound_meta_call --> { call(Goal) }.
% Unexpected: ERROR: Type error: `callable' expected, found `_13178,_13184=_13186' (a compound)
bad_dcg_unbound_meta_call --> { Goal }.

Reproduces on Mac OS with version 8.3.28 and on ubuntu with version 8.2.4, so it seems like this issue exists for a while, which is not surprising because it only occurs in erroneous code in the first place.
Still, this makes debugging the original error of using an unbound variable much harder to find.

Here’s a slightly more practical example where this issue may arise:

foo(TestGoal) --> ( { TestGaol } -> bar ; baz ).

The typo in { TestGaol } trigger the compile time error, where a singleton variable warning is due.

2

I get the messages below after compiling. Sure, the error message could be be improved. SWI-Prolog refuses to compile clauses where the compiler detects they cannot run anyway, mostly as a result of fresh variables in places that are subject to compilation and where a fresh variable makes no sense. I think that is ok. One could argue about dynamic code, but especially for static code I see little point in compiling code that can’t be executed.

Warning: /Users/jan/src/swipl-devel/build/e.pl:8:
Warning:    Singleton variables: [TestGoal,TestGaol]
ERROR: /Users/jan/src/swipl-devel/build/e.pl:8:
ERROR:    Type error: `callable' expected, found `_31678,_31684=_31686->bar(_31684,_31692);baz(_31686,_31692)' (a compound)
3

Thanks you for the response Jan.
You are right, SWI-Prolog both prints the expected warning and fails to compile, I was mistaken implying above that the warning in eluded.
(I’ve been blinded by my IDE showing only the error for that line without the warning).
I see your point about not wanting to compile code that can’t be successfully executed, but at least for me this behavior was quite surprising and hard to debug, imagine an ugly mid-refactor nonterminal that has more than one Singleton variable in the same line, one of which is used as a meta call as above triggering the error.

Anyway I’ll attempt posting a PR for a suggestion for improving the error message.