SWI-Prolog's strategy for reloading code is described here. The main consequence is that the new code remains invisible until the reload process has completed. This is typically ok, unless term_expansion/2 (or goal_expansion/2) relies on previously loaded code. This includes the definition of term/goal expansion itself. Possible solutions
- Run term/goal expansion in the future state. Not sure this is easily feasible
- Update the visible code per predicate rather than per file. This is basically ok as safe reloading of
running code can only be guaranteed if the interfaces of the predicates do not change.
- Add dedicated hooks to query predicates and clauses of the future version. That is already
available as predicate_property(Head, defined), but this seems a slippery slope.
SWI-Prolog's strategy for reloading code is described here. The main consequence is that the new code remains invisible until the reload process has completed. This is typically ok, unless
term_expansion/2(orgoal_expansion/2) relies on previously loaded code. This includes the definition of term/goal expansion itself. Possible solutionsrunning code can only be guaranteed if the interfaces of the predicates do not change.
available as
predicate_property(Head, defined), but this seems a slippery slope.