/usr/share/mozart/doc/apptut/node4.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>3 Module Managers</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="node3.html#chapter.development"><< Prev</A></TD><TD><A href="node1.html">- Up -</A></TD><TD><A href="node5.html#chapter.pickle">Next >></A></TD></TR></TABLE><DIV id="chapter.modman"><H1><A name="chapter.modman">3 Module Managers</A></H1><P> So far we only dicussed how functor definitions can be developed in a modular fashion. This chapter explains how modular applications are executed. </P><P> The chapter is kept informal, a more detailed explanation of module managers and how module managers link applications can be found in <A href="bib.html#modules.98">[DKSS98]</A>. </P><DIV id="section.modman.overview"><H2><A name="section.modman.overview">3.1 Overview</A></H2><P> A module manager maintains a <EM>module table</EM>. The module table maps urls (or to be more precise, full module urls) to modules or futures to modules. </P><P> A module manager <EM>links</EM> a module at url <I>U</I> as follows: </P><OL type="1"><LI><P>If <I>U</I> is already in the module table, the module manager returns the entry in the module table. </P></LI><LI><P>If <I>U</I> is not yet in the module table, the module manager creates a new future <I>M</I> and stores <I>M</I> under key <I>U</I> in the module table. As soon as the value of future <I>M</I> gets requested, the module manager <EM>installs</EM> a module from the url <I>U</I>. </P></LI></OL><P> </P><P> Linking is done lazily: only when the value of the module is requested (usually implicitly, when the application attempts to access an exported feature), the module gets installed. A module with full module url <I>U</I> is installed as follows, where the installation procedure returns a module <I>M</I>: </P><OL type="1"><LI><P>The pickled functor stored at <I>U</I> is loaded. </P></LI><LI><P>The module manager computes the full module urls for its imports. This step is detailed in <A href="node4.html#section.modman.import">Section 3.3</A> and <A href="node4.html#section.modman.resolve">Section 3.4</A>. </P></LI><LI><P>It recursively links all functors with the full module urls computed before. This yields the <EM>argument modules</EM>. </P></LI><LI><P>It applies the functor body to the argument modules, which returns the module <I>M</I>. </P></LI></OL><P> </P></DIV><DIV id="section.modman.lazy"><H2><A name="section.modman.lazy">3.2 Lazy Linking</A></H2><P> In the above section we have discussed that modules are subject to lazy linking: Only when a module is requested, the functor to compute that module gets loaded. </P><P> Lazy linking has dramatic effect on the startup time of an application: applications can start small in a fraction of a second and load additional functionality on demand. And all this happens completely transparently. </P><P> System modules are also subject to dynamic linking. Even though module managers give the impression that the system modules are always there, they are also loaded on demand. An application that takes good advantage of that fact is for example the Oz Programming Interface which starts quickly even though it imports all system modules. </P></DIV><DIV id="section.modman.import"><H2><A name="section.modman.import">3.3 Import Specifications</A></H2><P> The entire import part of a functor is called the <EM>import specification</EM>. Each import specification consists of several <EM>import clauses</EM>. Each import clause consists of a mandatory <EM>module name</EM> and an optional <EM>module url</EM> that must be preceded by the <CODE><SPAN class="keyword">at</SPAN></CODE> keyword. </P><P> For example, in the import specification </P><BLOCKQUOTE class="code"><CODE><SPAN class="keyword">import</SPAN> <BR> DB<BR> MyForm <SPAN class="keyword">at</SPAN> <SPAN class="string">'Form.ozf'</SPAN></CODE></BLOCKQUOTE><P> the first import clause is <CODE>DB</CODE> which just consists of the module name <CODE>DB</CODE> and does not provide a module url. The second import clause is <CODE>MyForm <SPAN class="keyword">at</SPAN> <SPAN class="string">'Form.ozf'</SPAN></CODE> which consists of the module name <CODE>MyForm</CODE> and the module url <CODE><SPAN class="string">'Form.ozf'</SPAN></CODE>. </P><P> The first step in linking a functor is that the module manager computes for each import clause the <EM>full module url</EM>. This is done according to the following rules: </P><OL type="1"><LI><P>If the import clause features a module url <I>U</I>, the full module name is <I>U</I>. </P></LI><LI><P>If the import clause consists of a module name <I>M</I> only, where <I>M</I> is the name of a system module, the full url is <CODE>x<SPAN class="keyword">-</SPAN>oz:<SPAN class="keyword">//</SPAN>system<SPAN class="keyword">/</SPAN></CODE><I>M</I>, that is the module name prefixed by <CODE>x<SPAN class="keyword">-</SPAN>oz:<SPAN class="keyword">//</SPAN>system<SPAN class="keyword">/</SPAN></CODE>. </P></LI><LI><P>If the import clause consists of a module name <I>M</I> only and <I>M</I> is not the name of system module, the full url is <I>M</I><CODE><SPAN class="keyword">.</SPAN>ozf</CODE>, that is the module name suffixed by <CODE><SPAN class="keyword">.</SPAN>ozf</CODE>. </P></LI></OL><P> </P><P> All currently defined system modules are listed in <A href="node4.html#table.modman.system">Table 3.1</A>. </P><DIV class="table" id="table.modman.system"><HR><P><A name="table.modman.system"></A></P></DIV><TABLE align="center" bgcolor="#f0f0e0" id="table.sysmods"><TR valign="top"><TH><P>Name</P></TH><TH><P>Description</P></TH><TH><P>Documentation</P></TH></TR><TR valign="top"><TH colspan="3"><P>Application Programming</P></TH></TR><TR valign="top"><TD><P><CODE>Application</CODE></P></TD><TD><P>Command processing and application termination</P></TD><TD><P><A href="../system/node1.html#chapter.application">Chapter 1 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Module</CODE></P></TD><TD><P>Module managers</P></TD><TD><P><A href="../system/node7.html#chapter.module">Chapter 2 of ``System Modules''</A></P></TD></TR><TR valign="top"><TH colspan="3"><P>Constraint Programming</P></TH></TR><TR valign="top"><TD><P><CODE>Search</CODE></P></TD><TD><P>Search engines</P></TD><TD><P><A href="../system/node9.html#chapter.search">Chapter 4 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>FD</CODE></P></TD><TD><P>Finite domain propagators and distributors</P></TD><TD><P><A href="../system/node14.html#chapter.fd">Chapter 5 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Schedule</CODE></P></TD><TD><P>Scheduling propagators and distributors</P></TD><TD><P><A href="../system/node28.html#chapter.schedule">Chapter 6 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>FS</CODE></P></TD><TD><P>Finite set propagators and distributors</P></TD><TD><P><A href="../system/node33.html#chapter.fs">Chapter 7 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>RecordC</CODE></P></TD><TD><P>Feature constraints (record constraints with open arities)</P></TD><TD><P><A href="../system/node43.html#chapter.recordc">Chapter 8 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Combinator</CODE></P></TD><TD><P>Deep-guard combinators</P></TD><TD><P><A href="../system/node44.html#chapter.combinator">Chapter 9 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Space</CODE></P></TD><TD><P>First-class computation spaces</P></TD><TD><P><A href="../system/node45.html#chapter.space">Chapter 10 of ``System Modules''</A></P></TD></TR><TR valign="top"><TH colspan="3"><P>Distributed Programming</P></TH></TR><TR valign="top"><TD><P><CODE>Connection</CODE></P></TD><TD><P>Connecting to running Oz processes</P></TD><TD><P><A href="../system/node47.html#chapter.connection">Chapter 12 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Remote</CODE></P></TD><TD><P>Remote module managers</P></TD><TD><P><A href="../system/node48.html#chapter.remote">Chapter 13 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>URL</CODE></P></TD><TD><P>URL parsing and resolution routines</P></TD><TD><P><A href="../system/node49.html#chapter.urlurl">Chapter 14 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Resolve</CODE></P></TD><TD><P>URL resolving</P></TD><TD><P><A href="../system/node50.html#chapter.resolve">Chapter 15 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Fault</CODE></P></TD><TD><P>Handling faults in distributed programs</P></TD><TD><P><A href="../system/node52.html#chapter.fault">Chapter 17 of ``System Modules''</A></P></TD></TR><TR valign="top"><TH colspan="3"><P>Open Programming</P></TH></TR><TR valign="top"><TD><P><CODE>Open</CODE></P></TD><TD><P>Support for files, sockets, and pipes</P></TD><TD><P><A href="../system/node55.html#chapter.open">Chapter 20 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>OS</CODE></P></TD><TD><P>POSIX compliant operating system support</P></TD><TD><P><A href="../system/node56.html#chapter.os">Chapter 21 of ``System Modules''</A></P></TD></TR><TR valign="top"><TH colspan="3"><P>System Programming</P></TH></TR><TR valign="top"><TD><P><CODE>Pickle</CODE></P></TD><TD><P>Saving and loading of persistant values</P></TD><TD><P><A href="../system/node57.html#chapter.pickle">Chapter 22 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Property</CODE></P></TD><TD><P>Querying and configuring engine properties</P></TD><TD><P><A href="../system/node58.html#chapter.property">Chapter 23 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Error</CODE></P></TD><TD><P>Error handling routines</P></TD><TD><P><A href="../system/node77.html#chapter.error">Chapter 24 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Finalize</CODE></P></TD><TD><P>Automatic garbage collection for native entities</P></TD><TD><P><A href="../system/node79.html#chapter.finalize">Chapter 26 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>System</CODE></P></TD><TD><P>Miscellaneous system related procedures (printing)</P></TD><TD><P><A href="../system/node80.html#chapter.system">Chapter 27 of ``System Modules''</A></P></TD></TR><TR valign="top"><TH colspan="3"><P>Window Programming</P></TH></TR><TR valign="top"><TD><P><CODE>Tk</CODE></P></TD><TD><P>Classes and procedures for window programming</P></TD><TD><P><A href="../system/node81.html#chapter.tk">Chapter 28 of ``System Modules''</A></P></TD></TR><TR valign="top"><TD><P><CODE>TkTools</CODE></P></TD><TD><P>Predefined abstractions to handle menus, dialogs, and so on</P></TD><TD><P><A href="../system/node95.html#chapter.tktools">Chapter 29 of ``System Modules''</A></P></TD></TR><TR valign="top"><TH colspan="3"><P>Graphical Tools</P></TH></TR><TR valign="top"><TD><P><CODE>Browser</CODE></P></TD><TD><P>Incremental display of Oz values</P></TD><TD><P><A href="../browser/index.html">``The Oz Browser''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Panel</CODE></P></TD><TD><P>Monitor and configure the running engine</P></TD><TD><P><A href="../panel/index.html">``Oz Panel''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Explorer</CODE></P></TD><TD><P>Visual constraint programming tool</P></TD><TD><P><A href="../explorer/index.html">``Oz Explorer - Visual Constraint Programming Support''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Ozcar</CODE></P></TD><TD><P>Interactive debugger</P></TD><TD><P><A href="../ozcar/index.html">``The Mozart Debugger''</A></P></TD></TR><TR valign="top"><TD><P><CODE>Profiler</CODE></P></TD><TD><P>Profiling of Oz programs</P></TD><TD><P><A href="../profiler/index.html">``The Mozart Profiler''</A></P></TD></TR><TR valign="top"><TH colspan="3"><P>Miscellaneous</P></TH></TR><TR valign="top"><TD><P><CODE>ObjectSupport</CODE></P></TD><TD><P>Generic classes for object oriented applications</P></TD><TD><P><A href="../system/node96.html#chapter.objectsupport">Chapter 30 of ``System Modules''</A></P></TD></TR></TABLE><DIV class="table"><P class="caption"><STRONG>Table 3.1:</STRONG> System modules.</P><HR></DIV><P> </P></DIV><DIV id="section.modman.resolve"><H2><A name="section.modman.resolve">3.4 Url Resolution</A></H2><P> Given the full url names for each import clause, the module manager determines the urls from which functors are to be loaded by <EM>url resolution</EM>. Url resolution takes two urls (one is called the <EM>base url</EM> and the other is called the <EM>local url</EM>) as input and computes a new <EM>resolved url</EM>. The process of url resolution you already know from organizing your html-pages: a url for a relative href-link is resolved with respect to the base url of the containing document. </P><P> In this respect, a module manager will behave similarly to a web-browser. When it installs a module that was loaded from url <I>U</I>, the latter's full import urls are resolved with respect to <I>U</I>. <A href="node4.html#figure.modman.resolve">Figure 3.1</A> shows a small example, where the root functor has the absolute filename <CODE>/home/schulte/A.ozf</CODE>. </P><DIV id="figure.modman.resolve"><HR><P><A name="figure.modman.resolve"></A></P><TABLE align="center" bgcolor="#f0f0e0" id="table.url.resolution"><TR valign="top"><TH><P>Name</P></TH><TH><P>Resolved url</P></TH><TH><P>Import specification</P></TH></TR><TR valign="top"><TD><P><CODE>A</CODE></P></TD><TD><P><CODE>/home/schulte/A.ozf</CODE> </P></TD><TD><P></P><BLOCKQUOTE class="code"><CODE><SPAN class="keyword">import</SPAN> <BR> B <SPAN class="keyword">at</SPAN> <SPAN class="string">'down/B.ozf'</SPAN> <BR> C <SPAN class="keyword">at</SPAN> <SPAN class="string">'http://www.foo.org/C.ozf'</SPAN></CODE></BLOCKQUOTE><P> </P></TD></TR><TR valign="top"><TD><P><CODE>B</CODE></P></TD><TD><P><CODE>/home/schulte/down/B.ozf</CODE> </P></TD><TD><P>empty</P></TD></TR><TR valign="top"><TD><P><CODE>C</CODE></P></TD><TD><P><CODE>http://www.foo.org/C.ozf</CODE> </P></TD><TD><P></P><BLOCKQUOTE class="code"><CODE><SPAN class="keyword">import</SPAN> D <SPAN class="keyword">at</SPAN> <SPAN class="string">'D.ozf'</SPAN></CODE></BLOCKQUOTE><P> </P></TD></TR><TR valign="top"><TD><P><CODE>D</CODE></P></TD><TD><P><CODE>http://www.foo.org/D.ozf</CODE> </P></TD><TD><P>empty </P></TD></TR></TABLE><P class="caption"><STRONG>Figure 3.1:</STRONG> Example for resolving urls.</P><HR></DIV><P> </P></DIV><DIV id="section.modman.user"><H2><A name="section.modman.user">3.5 User-defined Module Managers</A></H2><P> When the engine starts it has the root module manager that executes the root functor and subsequently links imported functors. However, in many cases it is desirable that applications can create private module managers that just link particular functors. </P><P> As an example, suppose we want to use more than a single data base as implemented by the functor <CODE>DB.ozf</CODE> as shown in <A href="node3.html#section.development.db">Section 2.3</A> </P><P> In the Oz Programming Interface, we can link <CODE>DB.ozf</CODE> twice with two new and different module managers as follows: </P><BLOCKQUOTE class="code"><CODE>[DBA]={Module<SPAN class="keyword">.</SPAN>link [<SPAN class="string">'DB.ozf'</SPAN>]}<BR>[DBB]={Module<SPAN class="keyword">.</SPAN>link [<SPAN class="string">'DB.ozf'</SPAN>]}</CODE></BLOCKQUOTE><P> Both <CODE>DBA</CODE> and <CODE>DBB</CODE> refer to two independent data bases. </P><P> You can observe lazy linking easily. Browsing <CODE>DBA</CODE> as follows </P><BLOCKQUOTE class="code"><CODE>{Browse DBA}</CODE></BLOCKQUOTE><P> shows <CODE>DBA<Future></CODE>, which means that <CODE>DBA</CODE> still refers to a future. Requesting the module by, for example, adding an entry to the data base is also reflected in the Browser: the display of <CODE>DBA<Future></CODE> is replaced by a representation of the module's value. </P><P> That both module managers work independently can be verified by browsing <CODE>DBB</CODE>. </P><P> <CODE>Module<SPAN class="keyword">.</SPAN>link</CODE> takes a list of urls, creates a new module manager and maps each url <I>U</I> to the module created by linking the functor at <I>U</I>. Reference documentation can be found in <A href="../system/node7.html#chapter.module">Chapter 2 of ``System Modules''</A>. </P></DIV><DIV id="section.modman.opi"><H2><A name="section.modman.opi">3.6 Functors in the Oz Programming Environment</A></H2><P> Functors are first class entities in the language that can of course also be created in the Oz Programming Interface. This eases development of functors considerably. </P><P> Suppose the following demo functor definition </P><BLOCKQUOTE class="code"><CODE><SPAN class="keyword">declare</SPAN> <BR><SPAN class="keyword">functor</SPAN> <SPAN class="functionname">F</SPAN> <BR><SPAN class="keyword">export</SPAN> Pam<BR><SPAN class="keyword">define</SPAN> <BR> <SPAN class="keyword">fun</SPAN><SPAN class="variablename"> </SPAN>{<SPAN class="functionname">DoPam</SPAN> Xs P Ys}<BR> <SPAN class="keyword">case</SPAN> Xs <SPAN class="keyword">of</SPAN> nil <SPAN class="keyword">then</SPAN> Ys<BR> <SPAN class="keyword">[]</SPAN> X<SPAN class="keyword">|</SPAN>Xr <SPAN class="keyword">then</SPAN> {DoPam Xr P {P X}<SPAN class="keyword">|</SPAN>Ys}<BR> <SPAN class="keyword">end</SPAN> <BR> <SPAN class="keyword">end</SPAN> <BR> <BR> <SPAN class="keyword">fun</SPAN><SPAN class="variablename"> </SPAN>{<SPAN class="functionname">Pam</SPAN> Xs P}<BR> {DoPam Xs P nil}<BR> <SPAN class="keyword">end</SPAN> <BR><SPAN class="keyword">end</SPAN></CODE></BLOCKQUOTE><P> After feeding the definition, the defined functor can be applied as follows: </P><BLOCKQUOTE class="code"><CODE>[M]={Module<SPAN class="keyword">.</SPAN>apply [F]}</CODE></BLOCKQUOTE><P> The module <CODE>M</CODE> can be used in the OPI as usual, that is </P><BLOCKQUOTE class="code"><CODE>{Browse {M<SPAN class="keyword">.</SPAN>pam [1 2 3] <SPAN class="keyword">fun</SPAN><SPAN class="variablename"> </SPAN>{<SPAN class="functionname">$</SPAN> I} I<SPAN class="keyword">+</SPAN>1 <SPAN class="keyword">end</SPAN>}}</CODE></BLOCKQUOTE><P> displays the list <CODE>[4 3 2]</CODE>. </P><P> <CODE>Module<SPAN class="keyword">.</SPAN>apply</CODE> takes a list of functors as argument, creates a new module manager, applies each functor element and returns the resulting list of modules. It is also possible to specify the base url used in linking the argument modules of the applied functor. For more information see <A href="../system/node7.html#chapter.module">Chapter 2 of ``System Modules''</A>. </P><P> Of course, also other situations allow to take advantage of first-class functors and that they can be applied by module managers. In particular they are useful for remote module managers that create new Oz processes on networked computers. You can learn more on this issue in <A href="../dstutorial/index.html">``Distributed Programming in Mozart - A Tutorial Introduction''</A>. </P></DIV></DIV><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="node3.html#chapter.development"><< Prev</A></TD><TD><A href="node1.html">- Up -</A></TD><TD><A href="node5.html#chapter.pickle">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>
|