Re: Prolog module system

I agree with you on almost all what you said.
But I have two observations:

1) I do not think I am trying to build something on the "shaky" ground of
the current module system, but I think that, if a new architecture has to
come, it has to guarantee compatibility with old stuff;

2) I do not think one should feel himself/herself embarrassed because of
comparision among languages, especially when talking of their most
fashionable properties: I think a prolog programmer could, if he/she wants,
to embarrass whoever;

Well, I think prolog offers so much freedom that one can build its own
object-oriented extension in less than 300 source code lines, redefining
system procedures, actually doing what he/she wants. But one should keep in
mind: what all these OOP features really add to prolog? My view is moving
towards minimalism. In this respect, I can only justify an extension to
prolog that does not create another language, adding so many predicates,
and, above all, not really so useful concepts (now I am blunt ;).

Cheers,

Mauro


"Paulo Moura" <pjlmoura@xxxxxxxxx> ha scritto nel messaggio
news:1181203722.500379.166320@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jun 5, 1:47 pm, "Mauro Di Nuzzo" <pico...@xxxxxxxxx> wrote:
...
Yes I know all this has a meaning, but I think the current module system
is
simply another way to estrange programmers from prolog.

We talked a bit about this on the Prolog standardization forums but is
worth repeating it here: most current module systems fail at the very
basic thing they ought to support: avoiding name conflicts by
providing namespaces when defining predicates.

Let's assume two common library modules, each one exporting a member/2
predicate:

:- module(lists, [member/2]).
...

:- module(sets, [member/2]).
...

So far, all is well. Both modules define a member/2 predicate, which
is a nice, short, descriptive name. Each modules implements the member/
2 predicate accordingly to its nature. Both modules are commonly part
of Prolog libraries. Now assume the user defines a third module, which
happens to call both lists:member/2 and sets:member/2.

Two options here. The first one is to use explicit module
qualification. This was the advantage of avoiding the name conflict
that would arise if both modules are imported. However, there is often
(but not always as Joachim pointed out elsewhere) a performance
problem in using explicit qualification, up to the point that some
Prolog implementers want to get rid of explicit qualification or
strongly discouraged its use. The second option is to use implicit
qualification. However, this leads to a name conflict. The common
solution is to rename the conflicting predicates in the defining
modules! (At this point, you may want to take a look at your favorite
Prolog compiler libraries.) This is simply the wrong place and the
wrong way of solving the problem. When renaming of a predicate is
needed to avoid a conflict, the renaming should take place in the
importing modules, not in the definition modules. Renaming in the
definition modules is equivalent to saying that modules provide
namespaces but we still need to rename predicate names to make them
unique in order to avoid usage conflicts! Thus, why use modules in the
first place? To be able to use short, nice, descriptive names only for
private, not exported predicates? People reusing a module care first
and foremost about the module interface, not about the module
internals. At the very least, modules should support renaming *on
importing*. Not only for solving name clashes but also to be able to
give an imported name an alias that is more meaningful in the context
where is going to be used.

Of course, the problem I just described, is just one of the
shortcomings of Prolog modules for software engineering tasks. Solving
this shortcomings amounts to people reinventing objects. Worse, people
are trying or hoping to reinvent objects as an extension and on such a
shaky ground as current module systems (look at the issues with e.g.
operators or meta-predicates). And this is just a very sad, big waste
of time (sorry Mauro to be so blunt).

I will end this post with a Prolog dirty secret: there is not support
for abstract data types (ADTs) in current module systems. Supporting
ADTs implies being able to define different implementations for the
same module *interface*. Clever programmers will find a way around
this limitation (they always do). However, lack of support for ADTs in
current module systems is so embarassing when talking to people using
other high-level programming languages...

All the best,

Paulo



.

Relevant Pages

  • Re: Prolog module system
    ... We talked a bit about this on the Prolog standardization forums but is ... Both modules define a member/2 predicate, ... this leads to a name conflict. ... shaky ground as current module systems (look at the issues with e.g. ...
    (comp.lang.prolog)
  • Re: Sublists question
    ... I do not really get what the predicate means or does. ... >>helps just to write the predicate out clearly in natural language, ... >>then translate into Prolog. ... more as a functional programming language than as a logic ...
    (comp.lang.prolog)
  • Re: Prolog, memory management and memory leaks
    ... predicate is executed that solves constraint problem. ... In some circumstances, this server leaks memory. ... "Understanding Memory Management in Prolog ... There is not just one garbage collector in Prolog. ...
    (comp.lang.prolog)
  • Re: Prolog module system
    ... my experiment with oop and modules has almost reach a point ... On the other hand, when I came to Prolog as a logic programming language, I ... Consider the length/2 predicate. ... OO systems have much more complex built-in lookup rules. ...
    (comp.lang.prolog)
  • Re: Books or Implementations and ISO Prolog.
    ... "The Craft of PROLOG" O'Keefe ... some vendors claim a strong interest in ISO Prolog I could find no ... there some reason for this apparent disregard for the ISO standard? ... OTOH, their module systems are ...
    (comp.lang.prolog)
Loading