To consolidate – I put all semantic checking code into one module, say, semantic_checks.
I then noticed that including an expansion within that module doesn’t work, since at the caller site the term isn’t expanded and the call occurs.
In fact there is no expansion in the semantic_check module either – somehow the pre-processor identifies that, and doesn’t do it – in my case it would be a call to true – after expansion – which doesn’t make sense (i think) – so, this is a good thing.
The only further remedy that is efficient I see is to include the term_expansion code in all modules that have such optional code.
I guess if term_expansion would propagate “upwards” to the caller site then this would work.
Perhaps a new compile time flag/directive could be added to allow that.
I guess, the same effect could be had if conditional compilation could work at the clause level – removing a clause, based on a custom compilation flag.
There is, i guess, another option: to wrap the expanded term into an “external” predicate – the caller calls the external predicate and inside of it, the clause is expanded to true. Leading to an “empty” call.
However, this adds a call overhead across the whole code base, where semantic checks are needed – just to overcome this problem.