<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">
Modules with rules defining views may be rewritten for optimization. 
A number of rewritings are 
supported. The primary rewriting technique is the {\em magic sets rewriting},
and its variant, the {\em supplementary magic sets rewriting}. By convention,
view definitions are stored in files with a .P suffix. They are consulted using
the {\em consult} command. If the file {\em blah.P} is consulted and rewritten,
the rewritten output is stored in {\em blah.P.M} for ease of debugging, and
for the user's edification.

The rewriting techniques run in separate processes independent of the main
CORAL process. CORAL writes out the module definition to a temporary file,
 and then invokes the rewriting process on it. The rewriting produces
a transformed module in which the rules have been rewritten for optimization.
This rewritten module is now consulted.

At the end of a module, the parser calls {\em parserStruct.execute()}. If
the module has the rewriting flag on, then the contents of the parserStruct
get written out to a temporary file, and the appropriate rewriting process
is called on it. The function that does this is {\em perform\_rewriting}
in {\em Rewriting.C}. The ouput of the rewriting is then fed back into the
input of the scanner, and this time the module has the rewriting flag
turned off, so that it is not sent for rewriting again.

\subsection{Read At Your Own Risk}

One thing to note is that when the module is written out to the temporary
file for rewriting to occur, all the system default annotations are added
to it, though of course, the defaults in the original definition have
precedence. The way this is done is : parserStruct has fields for all
the possible annotations. These get initialized to the system defaults 
contained in exEnv (execution environment).
Now when the module is parsed, any annotations in the module change
the fields in the parserStruct ({\bf not} in exEnv). When the module
is written out to the temporary, all the annotations in the parserStruct
are written along with it. This is essential, since the rewriting
process does not know what the current set of defaults for CORAL are.

Another subtle point is that if there are multiple modules defined in
{\em blah.P}, all their rewritten versions need to be stored in {\em blah.P.M}
(because this is what is meaningful to the user). However, as far as
the parser is concerned, it is as though each of these modules was being
independently typed in at the prompt. To overcome this, the filename
info is stored along with the input stream on the scanner input stack.

Further subtle point: if a module exports a number of query forms, it
is treated as though there were a copy of the module consulted for each 
exported query form.

Yet another subtle point: there's absolutely nothing subtle about any of this.
Just checking if you were awake.

\noindent
Files to look at:
{\em
\begin{itemize}
\item Rewriting.C : contains perform\_rewriting()
\item ParseUtils.C : contains EndModuleFunction
\item Unparse.C : contains routines to print out a module
\end{itemize}
}

</pre></body></html>