next up previous contents index
Next: Static and Dynamic Code Up: Using the System Previous: Sample Session

Organization of Consulted Files

   

Slightly more care than usual must be taken in organizing program files in compiled CLP( tex2html_wrap_inline4020 ). A file consists of a number of chunks. Each chunk consists of a zero or more rules (defined in the usual way) possibly followed by a goal. That is, a goal always closes off a chunk, and the end of the file closes off the last chunk if a goal has not done so. bsphackfloatpenalty -Mii floatpenalty-Miii parmoderrfloatpenalty@ nextcurrboxfreelist currbox-2floatpenalty@ fltovf currboxtempboxa tempboxa @floatesphackbsphackfloatpenalty -Mii floatpenalty-Miii parmoderrfloatpenalty@ nextcurrboxfreelist currbox-3floatpenalty@ fltovf currboxtempboxa tempboxa @floatesphack A relation may not span more than one chunk unless it has been declared to be dynamic (see below) before the first rule defining it. Defining a relation statically in more than one chunk will generate a warning message stating that the new definitions will be ignored is given. However if one is reconsulting then the new definitions will replace the ones defined in the previous chunk. A warning message that the redefinition has taken place is also given. However, if such a redefinition during a reconsult is not possible when the earlier definition has been protected (using the prot/2 predicate), in which case a warning is printed and the new definition is ignored.  bsphackfloatpenalty -Mii floatpenalty-Miii parmoderrfloatpenalty@ nextcurrboxfreelist currbox-4floatpenalty@ fltovf currboxtempboxa tempboxa @floatesphack The motivation for this restriction is that the state of the rulebase needs to be well defined whenever a goal is encountered in the consulted file.

There may be three kinds of goals in any consulted file.   All three kinds are considered to be identical (and behave in the usual way) when they are encountered in a source file that is being consulted. However, they are different when a source file is first compiled and when the .clam file is consulted. All goals of the form :- goal are only executed during the compilation stage. Those of the form ::- goal are only executed during the consultation of the compiled code, and the goals of the traditional form ?- goal are executed twice: once during compilation and once during consultation. In summary:


:- goal.

is executed during compilation of the source file.

::- goal.

is executed during consultation of the .clam file.

?- goal.

is executed during compilation at runtime.

The first kind of goal might be used for compiler directives and messages to whoever is watching while some code is being compiled. The second kind might be used for making a program run itself straight after it is loaded. Finally, the third kind of goal is useful for things like operator declarations which need to be present for the remainder of a program to parse correctly and also when the program is running so that terms will print correctly, etc. bsphackfloatpenalty -Mii floatpenalty-Miii parmoderrfloatpenalty@ nextcurrboxfreelist currbox-2floatpenalty@ fltovf currboxtempboxa tempboxa @floatesphackbsphackfloatpenalty -Mii floatpenalty-Miii parmoderrfloatpenalty@ nextcurrboxfreelist currbox-3floatpenalty@ fltovf currboxtempboxa tempboxa @floatesphack An embedded goal that fails during execution will generate a warning message (see also warning/1). bsphackfloatpenalty -Mii floatpenalty-Miii parmoderrfloatpenalty@ nextcurrboxfreelist currbox-4floatpenalty@ fltovf currboxtempboxa tempboxa @floatesphack


next up previous contents index
Next: Static and Dynamic Code Up: Using the System Previous: Sample Session

Alan Borning
Fri Oct 8 12:51:18 PDT 1999