To the best of my knowledge (please correct me if I’m wrong), Prolog implementations can be grouped into three kinds according to their module systems:
those with no module systems (prefixing nothing), such as GNU Prolog;
those with atom-based module systems (prefixing both relation symbols and function symbols), such as XSB Prolog and BIM Prolog; and
those with predicate-based module systems (prefixing only relation symbols), which seem to be the majority, such as SWI-Prolog, YAP, Ciao, SICStus, etc.
The question:
Where can I find the rationale/justification/reason, the design document, for each module system, especially for atom-based module systems?
The only design document I could find was Cabeza & Hermenegildo 2000 “A New Module System for Prolog”, for Ciao’s predicate-based module system.
I think your categorization is close but not entirely correct. I think BIM is fine, but XSB (AFAIK) only prefixes function (predicate) symbols. The 3rd category is all derived from the Quintus module system. It represents modules as primary citizens that each have a table that map predicate symbols to predicates. At least, that is what SWI does, but I think it is also what the others do. So, there is no special prefixed symbol for lists:member/2, but a mapping lists --> the module and the modules predicate table from member/2 to the implementation. lists:member/2 is just a compound term.
I’m not familiar with relevant literature. SWI took the Quintus module system because its first application was ported from Quintus The Quintus motivation boils down to be able to take a non-modular program,
put a header with the exports on top of every file and be done. The but is in meta-predicates that require a meta-predicate declaration, causing the caller to prefix one or more arguments with its own module such that the meta predicate can call back in the right module. This is only needed for meta predicates that are exported from a module, not locally used ones. The reasoning to accept this but is that naive users do not use a lot of meta programming and users that understand meta programming are probably capable to deal with the complications. I’m not sure from where I have this story. Possibly the Quintus manual, one of the Quintus people or someone at some ICLP.
Others will probably know more about the other side of the coin.
If you can find a set of proceedings of the logic programming conferences (both International and American), I think you’ll some early papers on modules (Google Scholar can help also, but I don’t know how well it works for papers from the 1980s and 1990s). [I don’t have easy access to a university, so I can’t help you …]
My only recollection of the “early days” is that atom-based modules looked like they would be better for building large-scale programs (e.g., because you could rename atoms and terms) but in practice they were more verbose and fiddly than predicate-based modules and their advantages usually weren’t needed. When you think about it, the name is often the trivial part of a term; other details are more important (e.g., the order of subterms) and an atom-based module system won’t help you there — “glue” predicates are needed anyway to transform terms.
I wonder who invented Quintus’ module and library system? … I have a feeling it was Richard O’Keefe (or, at least, he put the finishing details on it).
I’m pretty sure Richard wrote a lot of the Quintus library, partly based on the public domain DEC10 Prolog library. No clue who designed the module system.
At the moment, the runtime system maintains only the calling context.
Lookup context is only needed by the compiler. Note that all other
Prolog implementations I know of have neither in the runtime system.
I will say that one of the essential features of the original Quintus
module system was
ZERO time overhead for pre-module code,
ZERO time overhead for code that doesn’t use call/N
When I say “essential”, I mean that David Warren kept on vetoing Dave
Bowen’s designs until we had a design that satisfied this requirement.
We did have to introduce the ‘logical’ semantics for the dynamic
data base, but since dynamic
A quick search suggests that forwards are handled different. That might actually be a good to avoid a lot of junk. My current workflow is anyway to use mail just to get notifications. I do all the work on this website. The only drawback is that you do no see in your mail that you replied. Discourse keeps a pretty good record of what has been done and needs to be done, so I now typically delete discourse messages from my email.
@jan Thanks for the correction. You are right: last week I tried to write a Prolog module system in Prolog, and I found that meta-predicate handling is somewhat tricky.
@peter.ludemann Google Scholar did return some papers with interesting titles:
1985 O’Keefe “Towards an Algebra for Constructing Logic Programs”
1986 Miller “A Theory of Modules for Logic Programming”
Unfortunately I can’t find the PDFs, and I’m in a third-world country (Indonesia), and I’m outside academia, so I don’t have access to libraries.
You are right: The name is less important than the shape of a predicate. It is the shape that determines what a predicate does.
@pmoura Thanks for the historical context. So performance is the rationale for the Quintus module system.