DCGs and consult/1 in the ISO Prolog Standard

Appeared in Volume 6/3, August 1993

dave@quintus.com
David Bowen
23rd April 1993

There is support in WG17 for including DCGs in the standard, but getting a definition that was generally acceptable took too long to get them in Part 1. Part of the problem seemed to be that some people wanted DCGs to be defined by a Prolog program that translated them into ordinary Prolog clauses, while others wanted them defined from first principles. I personally hope that there is a possibility to get DCGs into Part 2 of the standard which is less far along the standardization pipeline and which currently consists only of modules.

There are a couple of problems with getting consult/1 into the standard. One problem is what it means to consult the same file more than once. Quintus Prolog and some others use the "reconsult" semantics (based on the reconsult predicate in DEC10 Prolog) which deletes previous definition of each predicate that appears in the file. This is not quite "right" in the case where a predicate has been deleted from a file and the file is then consulted again, since there may still be calls to the deleted predicate. Another possibility is to have systems "unload" all the predicates that previously were defined in the file before consulting it a second time. This imposes some implementation overhead, and also makes it imperative that the Prolog system can always identify whether a file is one that has been previously consulted, which is not possible in general, especially in cases where Prolog states can be saved and then re-run later, possibly on a different machine.

There is a bit of extra complexity for multifile predicates, i.e. predicates for which clauses are spread across more than one file. In this case, there isn't really a "reconsult" option - it is necessary to remove the clauses which previously came from the file before consulting it for a second time. This means that the Prolog system must do the best it can at recognizing that a file has been consulted before, and it must know which clauses came from that file.

The other problem with consult is whether or not the "logical" semantics for database updates is required. That is, if consult changes the definition of a predicate which is currently running, does backtracking into that predicate still use the old clauses? If not, what does happen? Again, multifile predicates are a complicating factor.

Another issue is whether arbitrary goals are allowed in files that are consulted. Currently the standard defines a "Prolog text" to contain only clauses and a small set of allowable directives. You cannot just run some arbitrary goal run in the middle of consulting a file, even though many Prologs allow it. A related question is whether term_expansion should be supported. (term_expansion comes from DEC10 Prolog and allows clauses to be macro-expanded in Prolog.) In both cases, it has to be decided what state of the Prolog database can be assumed at the time the goal (or the term_expansion) is run. Prolog systems which support separate compilation of files tend to do different things in these cases than Prolog systems supporting incremental compilation.

Apart from reluctance to tackle these problems, the argument for omitting consult from the standard is that it is primarily a programming environment facility, not a part of the language. Many Prolog systems have a variety of ways of processing Prolog texts, e.g. a compile/1 predicate or a stand-alone compiler. So even if there were a standard consult/1, it might not be the best way to load your program into the database.

micha@ecrc.de
Micha Meier
26th April 1993

We've also had problems with specifying the functionality of the consult/compile predicates, until we decided to base them on modules and not on files. Then most of these problems disappear. One should normally consult only modules. The whole module is first erased and then the file is loaded. If you load a file which is not a module, you can adopt whatever strategy seems good for you, either adding or replacing, because loading plain files becomes less important.

[The draft ISO Prolog standard (March 1993 revision) is available, in PostScript form, by FTP from: ftp://ai.uga.edu/ai.prolog.standard/ Ed.]