Re: Prolog module system

Mauro Di Nuzzo wrote:

I'd like explicit qualification. In particular, I'd like a different behaviour of these two:

system:assert(foo(bar)).

and

assert(system:foo(bar)). % or, even badly, whatever:assert(system:foo(bar)).

While now they have an identical effect (i.e. to assert foo(bar) into module system).

You may want to have a look at how ECLiPSe does this. It has a clear
distinction between _lookup_module_ and _context_module_. The colon-
qualification there only affects where the predicate definition is
looked up. In your example:

:- module(m).
p :- system:assert(foo(bar)).

would use the definition of assert/1 which is exported from 'system',
but foo(bar) would still be asserted into module m. To assert into
a different module, you'd use the @/2 construct, which overrides the
context module, e.g.

:- module(m).
p :- assert(foo(bar))@othermod.

would assert into module 'othermod'. The two annotations can
of course be combined.


Bart Demoen wrote:
Just so you don't have the wrong idea about me: I think the
module system as done in many Prolog systems is quite bad.
It is high time someone came up with something better.

Before reinventing everything, have at least a look at the ECLiPSe
module system, which addresses some of the points that get commonly
complained about:

- it has proper mechanisms to resolve name conflicts
- colon-qualification doesn't cost anything
- it can optionally enforce hiding of local items
- it implements reexport (with a bit of OO flavour)
- it doesn't employ a 'user' module (nor equivalent)
- it controls not only visibility of predicate names, but also
names of records, global variables, syntax settings etc

What's maybe not so nice is that metapredicates are done quite
differently from the defacto standard.
Also, the module name space is still flat, which starts becoming
a problem when putting together applications with library components
from various origins.

Another system that has put a lot of effort into its module system
design is Ciao (www.ciaohome.org)


-- Joachim
.