Additional Concept for Attributed Variable Namespaces

[burs...@gmail.com]

Dear All,

Jekejeke Prolog features already for a while structured
module names. It also works for dynamic modules. For
example we can do the following on the top-level:

Jekejeke Prolog 2, Runtime Library 1.2.3
(c) 1985-2017, XLOG Technologies GmbH, Switzerland

?- [user].
foo/bar:test :- write(hello), nl.

Yes

?- foo/bar:test.
hello
Yes

Syntactically the extension was very simple. Normally
a qualified call reads as follows:

/* unstructured modules */

call --> callable
| atom : callable.

The syntax has changed as follows:

/* structured modules */

call --> callable
| module : callable.

module --> atom
| package / atom.

package --> atom
| package / atom.

The mapping to the file system is relatively easy,
packages correspond to directories, and modules correspond
to files. A dynamic module is created as a fallback when
the file is not found.

Now I have a problem with the new modules term/unify
and term/verify. They require traditionally a key of
the form of an atom, which will refer to an unstructured
module. And I am running out of name spaces.

For example I have a module suspend.pl, and in
this module I want to define:

freeze/2
when/2

Traditionally I would be forced to create two
extra modules, and then do the following:

/* unstructured solution */

Module freeze.pl:

define hooks for put_attr(V, freeze, K)

Module when.pl:

define hooks for put_attr(V, when, K)

Now on the other hand, if put_attr/3 would accept
structured keys, we could go with the following
solution. Namely we could simply do:

/* structured solution */

Module suspend.pl:

define hooks for put_attr(V, suspend/freeze, K)

define hooks for put_attr(V, suspend/when, K)

Such structured hooks already work on the top-level,
namely the following works already by the same mechanism
as the initial demo foo/bar:test call works:

?- use_module(library(term/unify)).
% 5 consults and 0 unloads in 96 ms.
Yes

?- [user].
foo/bar:attr_unify_hook(_, T) :- write('T='), write(T), nl.
^
Yes

?- put_attr(X, foo/bar, 3).
put_attr(X, foo/bar, 3)

?- put_attr(X, foo/bar, 3), X=abc.
T=abc
X = abc

So the problem is basically already solved. Except for
a small slight issue. I have currently barred dynamic modules
from inside a Prolog text. Because they are not yet correctly
allocated. Working on it...

[burs...@gmail.com]

The idea would be to adopt the Java nested classes
scheme. So basically if the module suspend would resolve
to the following module:

<package>/suspend

Then an inner module suspend/freeze or suspend/when
would resolve to the following module:

<package>/suspend$freeze

<package>/suspend$when

Better support for nested Java classes respective
nested Prolog modules could also give a better support
for the foreign function interface and the Java auto loader.

java compiled classes contain dollar signs
https://stackoverflow.com/a/11388863/502187

But since our Prolog interpreter doesn't compile anything,
on the file system no suspend$freeze or suspend$when file
would appear. At the moment directives like:

:- module(foo,[]).

:- module(bar,[]). /* nested module */

p(a).
p(b).
p(c).

:- end.

Would not yet be needed. We would allow the following,
and say the end user knows what he is doing, when he
references a package which is a module (sic!):

:- module(foo,[]).

foo/bar:p(a).
foo/bar:p(b).
foo/bar:p(c).

So the dollar sign would be automatic, as is in the
Java programming language. In source code, the dollar
sign does not appear, when refering to nestered classes.

[burs...@gmail.com]

I found some precendent for nested modules. Namely
the ECLiPSe Prolog system has directive:

begin_module/1 directive
http://eclipseclp.org/doc/bips/kernel/obsolete/begin_module-1.html

(There is even a modul_interface/1 directive, but
this is not the issue we are working on).
Unfortunately the documentation then says that
begin_module/1 is deprecated, and we also find

a module/1 directive. But when we lookup the
module/1 directive, we find that it is only
a shorthand for module/3. But we find it complicated
to introduce the nested module functionality

in module/3. But module/1 has been adopted by
SWI-Prolog. We find in SWI-Prolog:

module/1 directive
http://www.swi-prolog.org/pldoc/man?predicate=module/1

The sematics is such that the module/1 directive,
replaces a typein module. So basically we can locale
modules, but probably nesting modules further, such
that a locale module can have a local module child,

is not intended. Namely some testing reveals the
following replacement semantics:

Welcome to SWI-Prolog (threaded, 64 bits, version 7.6.0-rc1)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.

?- module(foo).
Warning: foo is not a current module (created)
true.

foo: ?- module(bar).
Warning: bar is not a current module (created)
true.

bar: ?-

We opted to revive begin_module/1 and added end_module/0
directive as well. The semantics is now that a typein
module is pushed and pop, and not simply replaced. An
error message is not issued:

Jekejeke Prolog 2, Runtime Library 1.2.3
(c) 1985-2017, XLOG Technologies GmbH, Switzerland

?- begin_module(foo).
Yes

(foo) ?- begin_module(bar).
Yes

(foo$bar) ?- end_module.
Yes

(foo) ?- end_module.
Yes
?-

Some initial testing shows that everything works fine,
especially our application area of attributed variables
can be convered. There is still some functionally missing.
so we are still a little busy.

See also:
Preview: Recursive Locale Modules Feature. (Jekejeke)
https://plus.google.com/+JekejekeCh/posts/cvV9DeGfTGp