`consult/1` unexpectedly compiles (not interprets) code

[rotu]

When loading code from a file, it is compiled by default and thus unavailable for runtime inspection. In SICStus, this can be specifically avoided by instead using consult/1:

By default, e.g. when using [myprog], code is compiled. Compiled code cannot be listed with listing/1. Using consult([myprog]) ensures that the code is interpreted, making it available for listing with listing/1.

Instead, in scryer, consult/1 seems not to preserve the clauses of a consulted procedure, so trying to use clause/2 or listing/1 throws an error like error(permission_error(access,private_procedure,bar/2),clause/2).

Related: #2020

[rotu]

The way to load files in SICStus into static procedures is with load_files/2, use_module/3 or the ISO ensure_loaded/1.

SICStus even uses the term "consult" in prose to contrast with compilation. as in:

A runtime system has the following limitations: ...

• Except in extended runtime systems: no compiler; compiling is replaced by consulting. Extended runtime systems do provide the compiler