Improve syntax error reporting by including source file names

[jjtolton]

Closes: https://github.com/mthom/scryer-prolog/issues/302#issuecomment-3437500642

Context of initial comments

⚠️ Work In Progress / Proof of Concept

This PR is opened for discussion purposes. The implementation demonstrates the feasibility of improving syntax error reporting but should be reviewed by someone more experienced with Scryer Prolog internals before merging.

Problem Currently, when syntax errors occur during file loading in Scryer Prolog, the error messages are not helpful for debugging:

?- main. %@ error(syntax_error(incomplete_reduction),read_term/3:10). This error only shows read_term/3:10 - the predicate where the error was caught, not the actual source file that contains the syntax error. This makes it extremely difficult to debug, especially when loading multiple files.

Solution This PR modifies the error reporting system to include the actual source file name and line number:

error(syntax_error(incomplete_reduction),'test_file.pl':8). Now developers can immediately identify:

Which file has the syntax error Which line in that file is problematic Changes Modified Files src/machine/machine_errors.rs

Added file_name: Option<Atom> field to MachineError struct Added set_file_name() method for setting the file name Updated error_form() to include file name in error context when available Updated all MachineError constructors to initialize file_name: None src/machine/machine_state.rs

Modified read_term() error handling to extract file name from stream Calls err.set_file_name(stream.file_name()) to propagate file information Testing Created a test file with a deliberate syntax error and verified the output:

Before:

error(syntax_error(incomplete_reduction),read_term/3:10). After:

error(syntax_error(incomplete_reduction),'test_syntax_error.pl':8). All existing tests pass with no regressions.

Impact This is a significant quality-of-life improvement for Scryer Prolog developers. The change:

✅ Maintains backward compatibility (error structure remains the same) ✅ Only adds information when available (doesn't break non-file streams) ✅ Follows existing error reporting patterns ✅ Has minimal performance impact Discussion Points This is a proof-of-concept implementation. Questions for maintainers:

Is this the right approach for propagating file information through errors? Should we handle other error types similarly? Are there edge cases or scenarios not covered?

[UWN]

Do no forget #302

All can be implemented with call_with_error_context/2.

[UWN]

This PR modifies the error reporting system to include the actual source file name and line number:

error(syntax_error(incomplete_reduction),'test_file.pl':8).

This is not a solution. Leave the hacked implementation defined part as is, and add additional information with call_with_error_context/2. That is exactly the reason why it is there.

[jjtolton]

This PR modifies the error reporting system to include the actual source file name and line number:

error(syntax_error(incomplete_reduction),'test_file.pl':8).

This is not a solution. Leave the hacked implementation defined part as is, and add additional information with call_with_error_context/2. That is exactly the reason why it is there.

Have a question here if that is what the result is supposed to look like

[triska]

It's interesting how much shorter and self-contained the change on the Prolog level is.