Re: Prolog module system

Wow! This discussion is really charming for I am learning much (actually,
this sharpens my opinion).

In particular, my experiment with oop and modules has almost reach a point
of no return. Modules are no suitable to implement even the flavour of
object oriented programming. Nevertheless, I think modules (with the related
import semantics) are a good and well established part of the Prolog
language. I just hope in minor improvements. To name one (for SWI), I would
appreciate a SWI version of the "blackboard" of SICStus. I mean that one
should be able to define constants per-module (I am going to add this
feature to my oop in order to treat attributes). This is really
straightforward to implement (see SICStus bb_set/2, bb_get/2, bb_delete/1,
bb_update/3 predicates).

On the other hand, when I came to Prolog as a logic programming language, I
expected a great part of such a language dealing with categories. Objects
must have a part in Prolog, but I do not believe that a "standard" oop can
improve Prolog (actually I think the contrary). Prolog is based on
predicates and unification. Consider the length/2 predicate. Logtalk
definition is identical to standard prolog (I cannot see the advantage,
sorry). Instead, within my oop, I define a length/1 predicate, the actual
list (i.e. data) being stored elsewhere in the instance. But consider now
what definition one could use for append/3 (unless using 3 different
predicates). [I hope I expressed myself in the latter point]. So, if data
must remain into the predicate (as an argument), why oop?

These reflections led me to an idea that unfortunately I am unable to master
(perhaps I will upload some unuseful code in my site in the future).
The core of the idea is to somehow inductively recognize the data arguments
of a predicate in order to decide what to do based on some taxonomic rules.
Deliriums...

Cheers --

Mauro Di Nuzzo



"Paulo Moura" <pjlmoura@xxxxxxxxx> ha scritto nel messaggio
news:1181979926.273377.126530@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jun 15, 11:25 pm, Joachim Schimpf <jschi...@xxxxxxxxx> wrote:
...
Module systems have simple lookup rules: you either call the visible
predicate (which is local or imported), or you module-qualify explicitly.

OO systems have much more complex built-in lookup rules.

Much more complex? Hardly. That sounds too much like FUD for me to be
quiet :-) It also omits the troubles that implicit qualification can
get you into. Is worth noting that the widespread success of OOP
languages shows that most people have no problem mastering and using
objects to solve everyday problems.

Let's take a look to object lookup rules. The first thing one needs to
be aware is that, with objects, there is a clear distinction between
*declaring* a predicate and *defining* a predicate (this distinction
often gets blurred with modules). Therefore, we have two lookup rules:
one for finding the predicate declaration (in order to show that a
call is legal; e.g. we're not calling a predicate that is out of
scope) and one for finding the predicate definition. The lookup rules
are different for prototype-based and class-based systems. Logtalk
supportd both types of systems. Alomost all (if not all) other OOP
systems only supports one of them.

Prototype-based systems:
Declaration lookup: if the declaration is not local, simply go up
on the prototype derivation relationships until you find it.
Definition lokup: the same.

Class-based systems:
Declaration lookup: start in the "self" class, follow
specialization relationships until you find it.
Definition lokup: can be the same (in most imperative-derived OOP
systems) or you can start locally and, if not found, go to the class
of "self" and then follow specialization relationships.

Inheritance semantics are not the same as import semantics (mind you,
Logtalk supports both). Import semantics look simpler until you import
several modules, each of them possibly importing other modules with
export and reexport directives coming into play, and with conflicting
predicate names. Then you start to appreciate the advantages of
explicit qualification and the advantages of language mechanisms for
solving name conflicts and for renaming (in the *usage* context)
inherited predicates.

One could be
bold and say that they effectively hide some module arguments and
module qualifications. That doesn't necessarily mean it's a bad idea,
but one has to ask whether the increase in language complexity is
justified by reduced application complexity.

One could be bold and say that one of the troubles of Prolog
implementers with objects is lack of familiarity on how to implement
them when compared with the accumulated expertise in implementing
modules. People usually cling to what they know best and are afraid of
change. The idea of replacing deeply encrusted module support in
source trees by object support is troublesome, so why not play some
smoke screens and talk how objects corrupt declarative and logic
programming ideals, conveniently omitting that the alleged corruption
is already there in plain Prolog and in Prolog module systems?

All the best,

Paulo



.

Relevant Pages

  • 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 module system
    ... I think prolog offers so much freedom that one can build its own ... 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: 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
    ... 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: Prolog: A Toy For Erudition
    ... them online in a better condition. ... about Prolog came after students asked suggestions for their homeworks. ... Since it is now necessary, I want to say, finally: I AM A BEGINNER. ... Why did you remove your oop package from your web site?... ...
    (comp.lang.prolog)