Simplify `multifile/1` directive
pmoura opened this issue · 4 comments
Line 322 in a2652fe
Can simply be (given that the directive is inside the planner module):
:- multifile max_plan_len/2.
I always module qualify those because it's better if somebody copy/pastes it into another module, then that gets loaded first, eeerk
That's one of the nasty things in the SWI-Prolog implementation of multifile/1 directives: any module can turn another module predicates multifile without the module owning the predicate clauses having any saying on the matter. For example:
:- module(m1, []).
:- multifile(m2:p/1).
m2:p(m1).:- module(m2, [p/1]).
p(m2).Then:
?- [m1, m2].
true.
?- p(X).
X = m1 ;
X = m2.
?- predicate_property(p(_), P).
P = interpreted ;
P = visible ;
P = static ;
P = (multifile) ;
P = imported_from(m2) ;
P = file('/Users/pmoura/Desktop/mwtf/m1.pl') ;
P = line_count(6) ;
P = number_of_clauses(2) ;
P = number_of_rules(0) ;
P = last_modified_generation(5650) ;
P = defined.
The first solution for p/1 now comes from m1. I.e. m1 just patched or hacked (depending on your perspective) m2.
I am perhaps more of a 'radical' than you. I often say to people that other languages protect you, Prolog gives you power. Yours is a perfect example of this:
a) Virtually all programmers would call this a 'bad thing to do' at best, a bug in the language at worst.
b) it could be a useful monkeypatch. Suppose m1 is your library, and m2 is source code you can't control. If it's the only way to meet the business need, I'd be glad to have it.
A similar debate appears in many languages over term_expansion/macros/preprocessors. Does the end (code that expresses design intent) justify the means (obscuring what the actual code is)?
Note that the above hack works in SWI-Prolog and YAP but not in ECLiPSe or SICStus Prolog. Patching can be forbidden or allowed in a fully controlled way without multifile backdoor tricks. See e.g.
https://github.com/LogtalkDotOrg/logtalk3/tree/master/examples/complements