Module Systems and Object-Oriented Prolog

[mauro]

As far I could remember, Prolog module system is a "de facto" standard.
So nothing prevent it to be left aside in a future standardization procedure, if any.

I guess whether it could be more useful than now. I mean that the actual module system could be modified in order to allow object-oriented paradigm, with a minimal effort and without changing the language substantially (i.e. it should be compatible with currently available modules).

What do you think about such a view?

Cheers,

[Paulo Moura]

First and foremost, is important to notice that the current ISO standard for Prolog modules is incompatible with almost all current module systems.

As far I could remember, Prolog module system is a "de facto" standard.

Far from it. If you restrict yourself to a few module directives (module/1-2, use_module/1-2, and export/1), is possible to write module code that run on most Prolog compilers that include a module system. Some caveats that you should be aware are operators, meta-predicates, and data hiding. Not all module systems make operators local to the module where they are declared. Not all module systems implement meta-predicates the same way (e.g. take a look to ECLiPSe, SWI-Prolog, and Quintus module systems). Most module systems allow you to call non-exported module predicates using explicit module qualification; only a few of them provide proper data hiding.

I guess whether it could be more useful than now. I mean that the actual module system could be modified in order to allow object-oriented paradigm, with a minimal effort and without changing the language substantially (i.e. it should be compatible with currently available modules).

What do you think about such a view?

Trying to modify the actual module systems in order to support OOP without substantial changes is hardly possible. Modules are broken at the most basic feature that you want from an encapsulation mechanism: namespaces. The goal of namespaces is to prevent name conflicts. Problem is, module predicates are used by importing them into another module. Therefore, in order to avoid conflicts, the (adopted) solution is to prefix module predicate names with the module name! Using module predicates through explicit qualification would avoid the need of adding a prefix to the predicate names. However, the use of explicit module qualification is often discouraged (some Prolog implementers go as far as suggesting that this feature be dropped) and usually implies a performance penalty (similar to the use of call/1). Moreover, none of the current module systems support a separation of interface from implementation allowing multiple implementations per interface. Thus, no support for abstract data types. The current year is 2007. Programming languages have come a long way since the birth of Prolog. Modules are next to worthless for solving software engineering problems when using Prolog as the main programming language. Clinging to current module systems is a sure bet to Prolog irrelevance for industrial applications. Trying to build useful code encapsulation and reuse features on top of such a shacky ground is not a worthy proposal.

All the best,

Paulo

[mauro]

Far from it.

Well, didn't you put "modules" in the current standard in this forum?
However, I agree with you in respect to my little experience. Once one is working with module predicates, ISO is gone.

On the contrary, as a Prolog user (neither commercial nor academic, I stresss this), I disagree with you when you deal with the current "shacky ground" for building something else (hopefully, object oriented programming).

With all the limits of my Prolog experience (you already know them), I was just saying that the current module system is pretty UNUSEFUL. Probably this is the reason because it is NOT part of the standard, yet.

...the use of explicit module qualification is often discouraged (some Prolog implementers go as far as suggesting that this feature be dropped) and usually implies a performance penalty...

Indeed, I cannot see one single reason to keep it, too.

Nevertheless, it seems to me that it could be worth trying to build something else. This is obviously far beyond me.

Cheers,

[Paulo Moura]

Well, didn't you put "modules" in the current standard in this forum?

I'm not following you. There is a *published* ISO standard for Prolog modules. The current forum categories and individual forums simply reflect the current published standards and the current work being done on Prolog standardization.

However, I agree with you in respect to my little experience. Once one is working with module predicates, ISO is gone.

On the contrary, as a Prolog user (neither commercial nor academic, I stresss this), I disagree with you when you deal with the current "shacky ground" for building something else (hopefully, object oriented programming).

Try the following experiment: rewrite your OOP package in order to run on most Prolog compilers that support a module system. Get back to us with your findings.

Probably this is the reason because it is NOT part of the standard, yet.

See above. There is already a module standard. Is just that nobody cares about it.

...the use of explicit module qualification is often discouraged (some Prolog implementers go as far as suggesting that this feature be dropped) and usually implies a performance penalty...

Indeed, I cannot see one single reason to keep it, too.

Without an explicit module qualification mechanism, you need an alternative solution for solving name conflicts. For example, assume that you have two modules, "lists" and "sets", both providing a member/2 predicate, and a third module importing the first two. How are you going to distinguish between calls to lists:member/2 and sets:member/2? The solution that you find in the libraries of Prolog compilers that support modules is to rename one or the two member/2 predicates in order to solve the conflict. Thus, you use modules to get namespaces and then, in order to use module predicates, you rename the predicates you want to export. Pathetic. If any renaming is needed, it should be done in the module importing the predicates, not in the imported modules. Otherwise, you cannot in practical terms reuse vocabulary (predicate names) between modules. Btw, renaming by the importing module is usually done for solving a conflict (in alternative to use explicit qualification) or to get a predicate name that is more meaningful in the context where it is being used.

Moreover, there are both advantages and disadvantages for both implicit qualification and explicit qualification. That's why most programming languages with encapsulation mechanisms support both forms of qualification.

All the best,

Paulo

[mauro]

Well, I think that it has to get rid of the concept of importing.
I think you know what I want to say.

Code: Select all

:- module(book, [author/1]).
author(kafka).
id(1).


I will expect, after module being loaded, suppose "from" module user (NOTE: I didnt say "into" module user):

Code: Select all

?- book:author(Author).
  Author = kafka


and, accidentally, but substantially:

Code: Select all

?- book:id(Id).
  ERROR: permission_error ...


Evidently:

Code: Select all

?- user:author(Author).    % or simply  ?- author(Author).
  ERROR: existence_error


Without the concept of importing, the predicate user:author/1 simply does not exists.

I am currently working on my OOP project to implement this behaviour.
Any suggestion is welcome.

[Paulo Moura]

Well, I think that it has to get rid of the concept of importing.

Maybe the following reference can help (among many that discuss the pros and cons of explicit versus implicit qualification):

Bjarne Stroustrup
The Design and Evolution of C++
Addison-Wesley
ISBN 0-201-54330-3

See chapter 17: Namespaces.

All the best,

Paulo

[Paulo Moura]

I am currently working on my OOP project to implement this behaviour. Any suggestion is welcome.

Instead of getting rid of "import", add conflict checking code that detects if a predicate exported by an imported module conflicts with a predicate of the importing module or with an exported predicate of other imported modules; if such a conflict exists, report it as an error or state clear rules for which predicate version will be used in such circumstances.

Allow the programmer to rename a imported predicate in order to solve a conflict or to provide an alias more meaningful in the context where the predicates will be used. For references, take a look at the Logtalk uses/2 directive or to other OOP languages such as Eiffel that deal with multi-inheritance conflicts.

All the best,

Paulo