Fine-grained multifile interfaces proposal

[hurufu]

Recently I was thinking what if I have a module that defines a multifile predicate, but I want some level of control on how it can be extended. For example I may want to allow heads of new clauses only when they are unifiable with my template.

Let's say I have the following predicate in my module:

:- module(greeting, [hello/2]).
:- multifile(hello/2).
hello(admin, "Hello admin").

I want others to import my module and being able to add their own hello/2, but with additional constraint: I want to restrict them to greet only user and not admin or anything else. So the following (new) clause should be allowed greeting:hello(user, "Hi"), but greeting:hello(root, "Hi") – shouldn't.

In my proposal you need to define an "interface":

hello(user, _) :- 0.

Which will be replaced during term expansion with a special predicate that will validate other clauses.

I'm open for comments and opinions.

[triska]

Is this (or should this be) limited to facts?

For example, what about the following clauses:

hello(U, "Hello admin") :- U = root.
hello(U, "Hello")       :- U = user.

Are they allowed/disallowed?

Or what about:

hello(U, "Hello") :-
        (   proof_of_twin_prime_conjecture_exists ->
            U = root
        ;   U = user
        ).    

In general, the value of U may not be decidable. For instance:

hello(U, "Hello", TM) :-
        (   turing_machine_halts(TM) ->
            U = root
        ;   U = user
        ).

[hurufu]

I've completely forgot to think that in general it is a much harder problem. Thanks for pointing this out. This means that it is much better if you use multifile predicate to implement wrapper and do some sanity checks in runtime. Like greet :- hello(user, X), write(X), nl.. This will still select correct predicate, and wouldn't rely on some compile-time checks. I think it is Ok to close this RFC :).