Re: Prolog module system

On Mon, 11 Jun 2007 16:17:49 -0700, Paulo Moura wrote:

In the context of module systems (...) ADTs are senseless for Prolog
if Prolog doesn't even support concrete data types.

I disagree. Consider, for example, the "dictionary" ADT. You can
implement dictionaries in Prolog using e.g. different types of trees.
With support for separating interface from implementation in a
encapsulation mechanism, you can *declare* predicates for working with
this ADT (e.g. empty/1, insert/4, lookup/3, keys/2, etc) in a
interface/protocol and then provide different *implementations* for
these predicates in different modules/objects, each one implementing a
dictionary data structure with its own set of trade-offs. Different
implementations can then coexist in the same application. Switching
implementations is easy as all of them use the same interface. This is
common practice in modern OOP languages. You can also do it in Prolog
by using Logtalk. While you (may) regard this as senseless, me and
others are happily taking advantage of this features :-)


I have seen Jan's replies and I agree with him: one can do this
minimalistic ADT thing in Prolog with the current module system
with only minimalistic surgery to the module system - I would go
with that instead of poluting Prolog with OO concepts.
I think that in this (minimalistic) sense I also agree with Mauro.

The argument for having types in Prolog - so that ADTs can be properly
supported - has not been made properly yet by me, so here it is:
it is clear that in a good module system, one wants to make it impossible
(or at least very difficult) to abuse it - call predicates that are not
made visible for instance. For ADTs, one would like to prevent (amongst
others) inspection of the ADT without using the interface predicates.
However, Prolog builtins like arg/3, ==/2 and functor/3 allow such
inspection of any term, so also of (the data part of) any ADT.
I am just naming the obvious builtins: clearly user preds can use the
builtin =/2 to inspect (and build) stuff.
Proper types would make that impossible (it would require some different
view on builtins like arg/3 or ==/2 - but [*]): Mercury has shown how to
do them in the context of a Prolog like language and also solved [*].

Mercury has a small variant of the Prolog module system that
makes ADTs (and much more more and usefull stuff) available to a Prolog
like language. My apologies to Mercury designers if the use of
"small variant" sounds condescending: I don't mean you did a "least
effort job starting from Prolog" - I know you didn't - it just feels like
a good way to sell your good ideas in this newsgroup.

Cheers

Bart Demoen
.

Relevant Pages

  • Re: Cross-Compiler development (MasterProlog/SWI/SICStus)
    ... >> things in Prolog). ... GNU Prolog does not have a module system. ... of Prolog compilers. ... Portability between a wide range of Prolog compilers is ...
    (comp.lang.prolog)
  • Re: Prolog module system
    ... module system as done in many Prolog systems is quite bad. ... No overhead is possible in a Logtalk language implementation whenever ... The *current implementation* does incremental compilation: ...
    (comp.lang.prolog)
  • Re: Prolog module system
    ... module system as done in many Prolog systems is quite bad. ... dynamic binding plus a caching mechanism, ... The *current implementation* does incremental compilation: ...
    (comp.lang.prolog)
  • Re: Prolog module system
    ... While now they have an identical effect (i.e. to assert foo(bar) into module ... module system as done in many Prolog systems is quite bad. ...
    (comp.lang.prolog)