Re: Prolog module system

On Jun 13, 5:47 pm, Joachim Schimpf <jschi...@xxxxxxxxx> wrote:
Paulo Moura wrote:
On Jun 13, 7:33 am, Zoltan Somogyi <z...@xxxxxxxxxxxxxxxxxxxx> wrote:
The notions that objects have (a) identity and (b) mutable state run directly
counter to the basic notions of declarative programming.

Is worth noting that, in current Prolog systems, modules have identity
and mutable state.

But there are very, very few situations where having mutable state in
a module is justified. I personally haven't used assert/retract in at
least 15 years of Prolog(-like) programming, and I think we all agree
that it is not the essence of LP, but rather an unfortunate blemish.

I was just pointing out that, in this particular point, there is no
distinction between modules and objects. So far, all criticism to
objects apply equally well to modules. Which, by itself is telling.

My main criticism of Logtalk is that it goes to great lengths
to provide features that not only encourage the use of global names and
mutable state, but elevate it to its prevalent programming paradigm.

What "great lengths" you're talking about? Logtalk reinterprets the
familiar dynamic database handling standard predicates in terms of
objects, as Prolog systems reinterpret the same predicates in terms of
modules. Logtalk provides built-in predicates for dynamically create
new objects at runtime. Most Prolog systems allows you to defined and
create new modules at runtime. So, once again, your (and others)
criticism of objects applies equally well to modules. Let me repeat my
question: what "great lengths" you're talking about?

Identity provides a way to refer to a set of encapsulated predicates
(or to an interface). I don't see how this goes either in favour or
against declarative programming.

It is fine to have names for your static code or data.
It is wrong to have names for dynamic data.

Then simply don't use dynamic objects. Nothing in Logtalk forces you
to do so.

Prolog have mutable state. In plain Prolog, we've a global dynamic
database. Using objects and modules, we've local dynamic databases.
Logtalk objects *can* have mutable state; they don't *need* to have
mutable state.

That would be acceptable if Logtalk had support for a kind of object
that behaves like a logical data structure.

Logtalk supports parametric objects (which, btw, predate Logtalk and
can be found in several other OO extensions and systems). They behave
like a logical data structure. With the added bonus of being able to
encapsulate the predicates that "work" in the data structure inside
itself.

Logtalk objects can be either static or dynamic; they can be defined
in a source file or created dynamically at runtime.

But they can't be anonymous like a Prolog structure or list.

Again, Logtalk supports parametric objects. Everytime you instantiate
object parameters you get a "variant" of the parametric object term.
Just the same as when you instantiate a Prolog structure of list.

That's
why I am not really sure they deserve to be called objects at all.
They certainly are not "first class".

Objects are not anonymous in ANY object-oriented language. An object
identity can be implicit but is always there.

Anyway, thanks for your feedback. It would be more intersting if you
had first taking a closer look at Logtalk.

All the best,

Paulo

.