One of the obstacles to Prolog success is…

… current module systems. The lack of a strong module standard is often touted as the reason behind the lack of portable Prolog libraries. Problem is, modules fail at everything that we want and need to accomplish when thinking about namespaces in Prolog. Data hiding? No, any module predicate can be called using explicit module qualification. You may think of a module predicate export list as the public module predicates but that’s only wishful thinking. Portability? Only if you forgo the use of operators and meta-predicates and restrict yourself to a subset of the Prolog compilers implementing a module system. The fact that the current ISO Prolog standard for modules is incompatible with the module systems found on most Prolog compilers does not help either. Separation between interface and implementation? No, simply not possible. Conflicts between imported predicates? Compiler errors and warnings will usually tell you there is a problem but modules do not provide mechanisms for solving the conflict other than reordering of import directives (that can only solve some of the problems). Ever wondered why module predicates often use a functor with a prefix which usually is the name of the module? The preferred and recommended way of using modules is through import directives and implicit qualification. Thus, we cannot reuse vocabulary between modules in fear of name conflicts (think polymorphism). Most current Prolog module systems simply do not provide the building blocks needed for the development of portable Prolog libraries. Without portable libraries, users are easily trapped into a single Prolog implementation. Want to shop around for third party libraries? You will be hard-pressed to find even vaporware.

Rats! This post ended up being a rant. I will try to behave next time.

2 Responses to “One of the obstacles to Prolog success is…”

  • Chris Mungall

    I hear what you’re saying, I would love to see some kind of module repository like CPAN or CRAN for Prolog, even if it was a minute fraction of the size.

    I’m less concerned about data hiding (which I think makes sense in an OO context, but not so much in a logic context), more about just getting the maximal amount of code reused for the minimum amount of effort.

    What if we did forego operators and meta-predicates? I like both of these, but I think you could get a decent core of reusable modules with a limited subset of prolog like this.

    I gave up trying to make modules reusable a while ago, as the two systems I was interested in (XSB for heavy duty deductive reasoning and SWI for modules and a nice environment) had utterly incompatible module systems. I’m encouraged to see the compatibility efforts between SWI and Yap, hopefully something will grow out of this. I have more faith in bottom-up efforts that top-down efforts like the ISO effort which is utterly opaque to me (where do I even read about what’s happening? Is there not even a web page or wiki page? I didn’t even know there was an ISO standard for modules)

    • Paulo Moura

      Logtalk objects give you predicate encapsulation like modules but with more powerful encapsulation and reuse mechanisms. Logtalk also provides you with a portable alternative to modules for working with XSB and SWI (and plenty more compilers!).

      About ISO work, see the Prolog Standardization links on the web page: