/usr/share/mozart/doc/apptut/node6.html is in mozart-doc 1.4.0-8ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>5 More On Functors</TITLE><LINK href="ozdoc.css" rel="stylesheet" type="text/css"></HEAD><BODY><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="node5.html#chapter.pickle"><< Prev</A></TD><TD><A href="node1.html">- Up -</A></TD><TD><A href="node7.html#chapter.deployment">Next >></A></TD></TR></TABLE><DIV id="chapter.mof"><H1><A name="chapter.mof">5 More On Functors</A></H1><DIV id="section.mof.computed"><H2><A name="section.mof.computed">5.1 Computed Functors</A></H2><P> We distinguish between <EM>compiled functors</EM> and <EM>computed functors</EM>. A compiled functor is obtained by compilation of a functor definition. Computed functors are obtained by executing compiled functors whose definitions contain nested functor definitions. Compiled functors can only have lexical bindings to the data structures of the base environment. Computed functors can have lexical bindings to all data structures that the creating compiled functors supply to their definitions. </P><P> Pickled computed functors can carry computed data structures with them. This matters since </P><OL type="1"><LI><P>a computed data structure can now be loaded together with a functor rather than being computed a new for each virtual machine using it. </P></LI><LI><P>the functors needed to compute the carried with data structure are not needed by the virtual machine using it. </P></LI></OL><P> </P><P> Computed functors are syntactically supported by a <CODE><SPAN class="keyword">prepare</SPAN></CODE><A name="label19"></A> and <CODE><SPAN class="keyword">require</SPAN></CODE><A name="label20"></A> section. For example, the root functor definition in the file <CODE>LMF.oz</CODE> can be rewritten using a <CODE><SPAN class="keyword">prepare</SPAN></CODE> section as follows: </P><P></P><DL class="anonymous"><DD class="code"><CODE><SPAN class="keyword">functor</SPAN> <BR><SPAN class="keyword">import</SPAN> <BR> DB Form % <SPAN class="comment">User defined<BR></SPAN> System Application % <SPAN class="comment">System<BR></SPAN><SPAN class="keyword">prepare</SPAN> <BR> Flights = </CODE><SPAN class="chunktitle"><SPAN class="chunkborder"><</SPAN><A href="node24.html#label74">Sample flights</A><SPAN class="chunkborder">></SPAN></SPAN><CODE> <BR><SPAN class="keyword">define</SPAN> <BR> %% <SPAN class="comment">Enter some flights<BR></SPAN> {ForAll Flights DB<SPAN class="keyword">.</SPAN>add}<BR> <SPAN class="keyword">...</SPAN> <BR><SPAN class="keyword">end</SPAN></CODE></DD></DL><P> </P><P> Here the difference between the compiled functor and the computed functor is that the compiled functor contains the code to create the list of sample flights. The computed functor just contains the list itself. </P><P> All variable identifiers that are introduced in the <CODE><SPAN class="keyword">prepare</SPAN></CODE> section are visible in the <CODE><SPAN class="keyword">define</SPAN></CODE> section. The variables introduced by the <CODE><SPAN class="keyword">import</SPAN></CODE> section are of course only visible in the <CODE><SPAN class="keyword">define</SPAN></CODE> section. </P><P> The <CODE><SPAN class="keyword">require</SPAN></CODE> section of a computed functors relates to the <CODE><SPAN class="keyword">prepare</SPAN></CODE> section as does the <CODE><SPAN class="keyword">import</SPAN></CODE> section to the <CODE><SPAN class="keyword">define</SPAN></CODE> section: modules imported in the <CODE><SPAN class="keyword">require</SPAN></CODE> section are available in the <CODE><SPAN class="keyword">prepare</SPAN></CODE> section. </P></DIV><DIV id="section.mof.import"><H2><A name="section.mof.import">5.2 Imports</A></H2><P> <CODE><SPAN class="keyword">import</SPAN></CODE> and <CODE><SPAN class="keyword">require</SPAN></CODE> specifications support features and fields. For example, in the main functor for our last minute flight booking system, we could have written the import clause for <CODE>DB</CODE> as follows: </P><BLOCKQUOTE class="code"><CODE>DB(add getAll remove)</CODE></BLOCKQUOTE><P> </P><P> Besides of the documentational advantage of explicitly listing the features, the compiler tries to enforce that only listed features are used for dot access. For example, given the above import clause, the following access </P><BLOCKQUOTE class="code"><CODE>DB<SPAN class="keyword">.</SPAN>addd</CODE></BLOCKQUOTE><P> raises an error during compilation. </P><P> In addition, also variables can be given as fields in the import specification as follows: </P><BLOCKQUOTE class="code"><CODE>DB(add:Add getAll:GetAll remove)</CODE></BLOCKQUOTE><P> The variables introduced for the fields interact with dynamic linking as follows: The module is requested as soon as the value for one of the variables is requested. </P></DIV></DIV><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="node5.html#chapter.pickle"><< Prev</A></TD><TD><A href="node1.html">- Up -</A></TD><TD><A href="node7.html#chapter.deployment">Next >></A></TD></TR></TABLE><HR><ADDRESS><A href="http://www.ps.uni-sb.de/~duchier/">Denys Duchier</A>, <A href="http://www.ps.uni-sb.de/~kornstae/">Leif Kornstaedt</A> and <A href="http://www.ps.uni-sb.de/~schulte/">Christian Schulte</A><BR><SPAN class="version">Version 1.4.0 (20110908185330)</SPAN></ADDRESS></BODY></HTML>
|