Next: , Previous: , Up: prolog   [Index]

16.4 Module system and prolog

We support @ and @@ operators to resolve atoms module meaning. The syntax is name@module which names files in a special module directory in the guile namespace (language prolog modules). @ is refering to symbols in the public interface and @@ refers to symbols in the whole private module namespace. We also support a guile-log reference through e.g. name@(logic,guile-log,iso-prolog). As a short cut to specify the module that issues a compilation of a prolog part we have the atom@ and atom@@, in principle this forces the module to the lexical module the code belongs to which is handy when we translate strings to atoms via the namespacing mechanism. compound objects can be specified belonging to a namespace which forces the objects inside the lexical atoms and strings to be namespaced to that namespace e.g. [a,'a-b',"axa"]@mod_a will translate all atoms inside the list to objects inside the public interface of module mod_a. The general rule is that lexical translation of objects outside the current module will need to be defined, the current module though will be created if it does not exist. For dynamic creation of atoms, we allow the objects to be created under some constraints.

prolog objects can be namespaced and contain namespace wrappers, which are transparent in the unification, but for logical variables that are namespaced if the matching object is a string, the variable will be located in the namespace if it exists or it will be constructed under some constraints.

We do not define a full prolog api for module handling, but refere to the usual scheme module system in guile and suggest that the user use the scheme stubs that can be inserted into guile prolog.

16.4.1 Example

:- scm[(use-modules (logic guile-log guile-prolog zip)]
:- scm[(export a b c)]
:- scm[(re-export e f g)]

16.4.2 module aware unification,

Strings will only in proven goals be translated to an atom in the module defining the string, else a string representation will remain. Still the evaluator understands that a string term shouled be represented by a procedure representing the predicate. The algorithm is to search in the current module runtime. But one may whish to explicitly translate strings to a correct module located predicate. The mechansim to achieve this is through the unification. The unification with respect to modules can also be used to verify that data adheres to a certain module convention. The rules for this is essentially

1) A variable in a module will if the other one is a string bind to a term/predicate found/defined in that module.

2) A term in a module will need to be proven to be defined in that module. unfourtunately it is possible that from scheme imported predicates does not declare in what module it is defined in which case we will not unify.

3) A namespaced object that is a datastructure like a list, closure etc, will make sure that all sub variables are bounded to a directly namespaced variable.

4) If a namespaced object has another namespaced object either the new one will take over or the unification fails depending on the state of the unifier to control what will happen see the api below.

subsubsection Example

 X@@module_a                 = ``alpha'',
 [X,Y,Z@@module_b]@@module_a = [``alpha'',''beta'',''gamma'']. % this may fail

16.4.3 Controling module unification

Sigilling a variable with X@module_a means that we will validate the curent data of the variable. It is desireable e.g. in sandboxing that the module environment cannot change. In the future we will be able to produce sandboxing, but in the current version it is not safe to use it, but we have prepared a little with the current codebase. To control this we can use the api that can be reached from,

scheme (use-modules (logic guile-log prolog namespace)).

prolog error_on_namespace_switch/0, fail_on_namespace_switch/0, ok_on_namespece_switch/0, with the obvious semantic.

Also to get an handle to restrict and guard this information one may use,


then if handle can be used by the dynamic features framework and make sure that we will never success although we move from state to state friously and a value can be guaranteed to be fixed inside a code segment.

It’s possible to specify a whitelist to handle if one allow changes of namespaces in a unification that include namespacing e.g.

prolog set_no_whitelist/0

prolog namespace_white_list_set([[Local, RW, dir, ...] ...])

prolog namespace_white_list_ref(ListOfList)

prolog namespace_white_list_handle(Handle)

Here Local = true/0 or false/0 specifies that the directory is allows referencing local defines or not, and RW = true/0 or false/0 specifies if the directory allow writing or not. If dir ends with "*" then any directories after that is included in the spec.

Next: , Previous: , Up: prolog   [Index]