Delay arithmetic syntax error

[hurufu]

PR for fixing #2454 issue.

Please review unit test that I've added, does it correctly describe the problem at hand? And does it make sense to add such a long running test?

[mthom]

I'm not sure what a satisfactory solution for #2454 should look like but I am hesitant to detect it from goal_expansion like we do for dcgs. It may make more sense to modify compile_is to generate code issuing an error at runtime rather than at compile time.

[hurufu]

Thanks a lot for suggestion. I also initially wanted to modify compiler code, but it explicitly produces an error if string is found that's why I made a conclusion that it is designed to throw an exception at compile time, and maybe it is even a good idea to show to the user that compilation wasn't successful... So I changed my general idea to do this rewrite (example): A is sqrt([]) ==> []=B, A is sqrt(B) behavior is the same, but error is delayed to the runtime. Also proper solution should be working both for consulting a file or asserting new predicate, and I'm not sure if goal expansion is done for assertions.

I don't have much time this weekend, I'll take a fresh look into the code next week probably and will see what it takes generate code that will issue an error.

[mthom]

I don't have much time this weekend, I'll take a fresh look into the code next week probably and will see what it takes generate code that will issue an error.

You may want to look at diag.pl and the instr! macro. diag.pl will give you examples of the WAM code to generate with instr!, starting from e.g.

f(X) :- throw(error(evaluable, X)).

Then wam_instructions(f/1, Is).