HPCC-9408 Document changes to the way MODULE inheritances works

Signed-off-by: Richard Taylor <richard.taylor@lexisnexis.com>

docs/ECLLanguageReference/ECLR_mods/Basics-AttributeVisibility.xml

@@ -6,14 +6,20 @@
       <primary>Definition Visibility</primary>
     </indexterm></title>
 
-  <para>ECL definitions are organized into modules (directories or folders on
-  disk). Within a module, you may define as many Definitions as needed. An
-  IMPORT statement (see the <emphasis role="bold">IMPORT </emphasis>keyword)
-  identifies any other modules whose visible Definitions will be available for
-  use in the current definition.</para>
+  <para>ECL code, definitions, are stored in .ECL files <indexterm>
+      <primary>.ECL files</primary>
+    </indexterm>in your code repository, which are organized into modules
+  (directories or folders on disk). Each .ECL file may only contain a single
+  EXPORT or SHARED definition (see below) along with any supporting local
+  definitions required to fully define the definition's result. The name of
+  the file and the name of its EXPORT or SHARED definition must exactly
+  match.</para>
 
-  <programlisting>IMPORT AnotherModule; //imports definitions from AnotherModule
-Definition1 := 5;     //as many definitions as needed</programlisting>
+  <para>Within a module (directory or folder on disk), you may have as many
+  EXPORT and/or SHARED definitions as needed. An IMPORT statement (see the
+  <emphasis role="bold">IMPORT </emphasis>keyword) identifies any other
+  modules whose visible definitions will be available for use in the current
+  definition.</para>
 
   <para>The following fundamental definition visibility scopes are available
   in ECL: <emphasis role="bold">"Global," Module</emphasis>, and <emphasis
@@ -27,52 +33,76 @@ Definition1 := 5;     //as many definitions as needed</programlisting>
         <primary>EXPORT</primary>
       </indexterm> (see the <emphasis role="bold">EXPORT</emphasis> keyword)
     are available throughout the module in which they are defined, and
-    throughout any other module that IMPORTs the module (see the <emphasis
+    throughout any other module that IMPORTs that module (see the <emphasis
     role="bold">IMPORT</emphasis> keyword).</para>
 
-    <programlisting>EXPORT Definition1 := 5;
-//make Definition1 available to other modules and
-//also available throughout its own module</programlisting>
+    <programlisting>//inside the Definition1.ecl file (in AnotherModule folder) you have:
+EXPORT Definition1 := 5;  
+   //EXPORT makes Definition1 available to other modules and
+   //also available throughout its own module</programlisting>
   </sect2>
 
   <sect2 id="Module">
     <title>Module</title>
 
-    <para>The scope of the Definitions defined as <emphasis
+    <para>The scope of the definitions defined as <emphasis
     role="bold">SHARED<indexterm>
         <primary>SHARED</primary>
       </indexterm></emphasis> (see the <emphasis role="bold">SHARED</emphasis>
     keyword) is limited to that one module, and are available throughout the
-    module (unlike local Definitions). This allows you to keep private any
-    definitions that are only needed to implement internal
-    functionality.</para>
-
-    <programlisting>SHARED Definition1 := 5;
-//Definition1 available throughout its own module, only
-EXPORT Definition2 := Definition1 + 5;
-//make Definition2 available to other modules and
-//also available throughout its own module</programlisting>
+    module (unlike local definitions). This allows you to keep private any
+    definitions that are only needed to implement internal functionality.
+    SHARED definitions are used to support EXPORT definitions.</para>
+
+    <programlisting>//inside the Definition2.ecl file you have:
+IMPORT AnotherModule;
+   //makes definitions from AnotherModule available to this code, as needed
+
+SHARED Definition2 := AnotherModule.Definition1 + 5;  
+   //Definition2 available throughout its own module, only
+
+//*****************************************************************************
+//then inside the Definition3.ecl file (in the sam efolder as Definition2) you have:
+IMPORT $;  
+   //makes definitions from the current module available to this code, as needed
+
+EXPORT Definition3 := $.Definition2 + 5;
+  //make Definition3 available to other modules and
+  //also available throughout its own module</programlisting>
   </sect2>
 
   <sect2 id="Local">
     <title>Local</title>
 
-    <para>A Definition defined without either EXPORT or SHARED (see the
-    <emphasis role="bold">EXPORT </emphasis>and <emphasis
-    role="bold">SHARED</emphasis> keywords) is available only to the
-    subsequent Definitions until the next Definition definition with EXPORT or
-    SHARED. This makes them private Definitions used only within the scope of
-    that EXPORT or SHARED Definition. This allows you to keep private any
-    definitions that are only needed to implement internal functionality.
-    Local Definitions are referenced by the Definition name alone; no
-    qualification is needed.</para>
-
-    <programlisting>MODULE abc;
-LocalAttr := 5;
-//local -- available through the end of Definition1's definition, only
-SHARED Definition1 := LocalAttr;
-//SHARED terminates scope for LocalAttr
-Definition2 := Definition1 + LocalAttr;
-//INVALID SYNTAX -- LocalAttr is out of scope here</programlisting>
+    <para>A definition without either the EXPORT or SHARED keywords is
+    available only to subsequent definitions, until the end of the next EXPORT
+    or SHARED definition. This makes them private definitions used only within
+    the scope of that one EXPORT or SHARED definition, which allows you to
+    keep private any definitions that are only needed to implement internal
+    functionality. Local definitions definitions are used to support the
+    EXPORT or SHARED definition in whose file they reside. Local definitions
+    are referenced by their definition name alone; no qualification is
+    needed.</para>
+
+    <programlisting>//then inside the Definition4.ecl file (in the sam efolder as Definition2) you have:
+IMPORT $;  
+   //makes definitions from the current module available to this code, as needed
+
+LocalDef := 5;
+  //local -- available through the end of Definition4's definition, only
+
+EXPORT Definition4 := LocalDef + 5;
+//EXPORT terminates scope for LocalDef
+
+LocalDef2 := Definition4 + LocalDef;
+  //INVALID SYNTAX -- LocalDef is out of scope here
+  //and any local definitions following the EXPORT
+  //or SHARED definition in the file are meaningless 
+  //since they can never be used by anything
+</programlisting>
   </sect2>
+
+  <para>See Also: <link linkend="IMPORT">IMPORT</link>, <link
+  linkend="EXPORT">EXPORT</link>, <link linkend="SHARED">SHARED</link>, <link
+  linkend="MODULE_Structure">MODULE</link></para>
 </sect1>

docs/ECLLanguageReference/ECLR_mods/ResrvdKywds-EXPORT.xml

@@ -6,27 +6,68 @@
 
   <para><emphasis role="bold">EXPORT<indexterm>
       <primary>EXPORT</primary>
-    </indexterm> </emphasis><emphasis>definition</emphasis></para>
+    </indexterm> </emphasis> <emphasis role="bold">[ VIRTUAL ]</emphasis>
+  <emphasis>definition</emphasis></para>
 
-  <para><emphasis>definition</emphasis> A definition.</para>
+  <para><informaltable colsep="1" frame="all" rowsep="1">
+      <tgroup cols="2">
+        <colspec colwidth="79.35pt" />
 
-  <para>The <emphasis role="bold">EXPORT </emphasis>keyword<indexterm>
-      <primary>EXPORT keyword</primary>
-    </indexterm> explicitly allows other definitions to import the specified
-  <emphasis>definition</emphasis>. Definitions not explicitly flagged for
-  export are local to the folder within which they reside. Without either the
-  SHARED or EXPORT keywords, a <emphasis>definitions's</emphasis> scope is
-  limited to the next SHARED or EXPORT.</para>
+        <colspec colwidth="309.45pt" />
+
+        <tbody>
+          <row>
+            <entry><emphasis role="bold">VIRTUAL</emphasis><indexterm>
+                <primary>VIRTUAL EXPORT</primary>
+              </indexterm></entry>
+
+            <entry>Optional. Specifies the <emphasis>definition</emphasis> is
+            VIRTUAL. Valid only inside a MODULE Structure.</entry>
+          </row>
+
+          <row>
+            <entry><emphasis>definition</emphasis></entry>
+
+            <entry>A valid definition.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </informaltable></para>
+
+  <para>The <emphasis role="bold">EXPORT </emphasis>keyword explicitly allows
+  other definitions to import the specified <emphasis>definition</emphasis>
+  for use. It may be IMPORTed from code in any folder, therefore its
+  visibility scope is global.</para>
+
+  <para>ECL code is stored in .ecl text files which may only contain a single
+  EXPORT or SHARED definition. This definition may be a structure that allows
+  EXPORT or SHARED definitions within their boundaries (such as MODULE,
+  INTERFACE, TYPE, etc.). The name of the .ecl file containing the code must
+  exactly match the name of the single EXPORT (or SHARED) definition that it
+  contains. </para>
+
+  <para>Definitions without the EXPORT or SHARED keywords are local to the
+  file within which they reside (see <link
+  linkend="Attribute_Visibility">Definition Visibility</link>). A local
+  <emphasis>definition's</emphasis> scope is limited to the next SHARED or
+  EXPORT definition, therefore they must precede that file's EXPORT or SHARED
+  definition.</para>
 
   <para>Example:</para>
 
-  <programlisting>EXPORT MyAttribute := 5;
+  <programlisting>EXPORT MyDefinition := 5;
+// allows other definitions to use MyModule.MyDefinition if they import MyModule
+// the filename must be MyDefinition.ecl
 
-// allows other definitions to use MyModule.MyAttribute if they import
-// MyModule</programlisting>
+//and in AnotherDef.ecl we have this code:
+EXPORT AnotherDef := MODULE(x)
+  EXPORT INTEGER a := c * 3;
+  EXPORT INTEGER b := 2;
+  EXPORT VIRTUAL INTEGER c := 3; //this def is VIRTUAL
+END;</programlisting>
 
   <para>See Also: <link linkend="IMPORT">IMPORT</link>, <link
   linkend="SHARED">SHARED</link>, <link
-  linkend="Attribute_Visibility">Attribute Visibility</link>, <link
-  linkend="MODULE_Structure">MODULE</link></para>
+  linkend="Attribute_Visibility">Definition Visibility</link>, <link
+  linkend="MODULE_Structure">MODULE Structure</link></para>
 </sect1>

docs/ECLLanguageReference/ECLR_mods/ResrvdKywds-SHARED.xml

@@ -6,25 +6,73 @@
 
   <para><emphasis role="bold">SHARED<indexterm>
       <primary>SHARED</primary>
-    </indexterm> </emphasis><emphasis>definition</emphasis></para>
+    </indexterm> </emphasis> <emphasis role="bold">[ VIRTUAL ]</emphasis>
+  <emphasis>definition</emphasis></para>
 
-  <para><emphasis>definition</emphasis> An Attribute definition.</para>
+  <para><informaltable colsep="1" frame="all" rowsep="1">
+      <tgroup cols="2">
+        <colspec colwidth="79.35pt" />
 
-  <para>The <emphasis role="bold">SHARED </emphasis>keyword<indexterm>
-      <primary>SHARED keyword</primary>
-    </indexterm> indicates an Attribute that is available for use throughout
-  the module (i.e. module scope). Without either the SHARED or EXPORT
-  keywords, an Attribute's scope is limited to the next SHARED or EXPORTed
-  Attribute</para>
+        <colspec colwidth="309.45pt" />
+
+        <tbody>
+          <row>
+            <entry><emphasis role="bold">VIRTUAL</emphasis><indexterm>
+                <primary>VIRTUAL SHARED</primary>
+              </indexterm></entry>
+
+            <entry>Optional. Specifies the <emphasis>definition</emphasis> is
+            VIRTUAL. Valid only inside a MODULE Structure.</entry>
+          </row>
+
+          <row>
+            <entry><emphasis>definition</emphasis></entry>
+
+            <entry>A valid definition.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </informaltable></para>
+
+  <para>The <emphasis role="bold">SHARED </emphasis>keyword explicitly allows
+  other definitions within the same folder to import the specified
+  <emphasis>definition</emphasis> for use throughout the
+  module/folder/directory (i.e. module scope), but not outside that scope.
+  </para>
+
+  <para>ECL code is stored in .ecl text files which may only contain a single
+  EXPORT or SHARED definition. This definition may be a structure that allows
+  EXPORT or SHARED definitions within their boundaries (such as MODULE,
+  INTERFACE, TYPE, etc.). The name of the .ecl file containing the code must
+  exactly match the name of the single EXPORT (or SHARED) definition that it
+  contains.</para>
+
+  <para>Definitions without the EXPORT or SHARED keywords are local to the
+  file within which they reside (see <link
+  linkend="Attribute_Visibility">Definition Visibility</link>). A local
+  <emphasis>definition's</emphasis> scope is limited to the next SHARED or
+  EXPORT definition, therefore they must precede that file's EXPORT or SHARED
+  definition.</para>
 
   <para>Example:</para>
 
-  <programlisting>BadPeople := Person(EXISTS(trades(EXISTS(phr(phr_rate &gt; '4'))));
-        //local only to the GoodHouses Attribute
+  <programlisting>//this code is contained in the GoodHouses.ecl file
+BadPeople := Person(EXISTS(trades(EXISTS(phr(phr_rate &gt; '4'))));
+        //local only to the GoodHouses definition
 SHARED GoodHouses := Household(~EXISTS(BadPeople));
-        //available all thru the module</programlisting>
+        //available all thru the module
+
+//and in AnotherDef.ecl we have this code:
+EXPORT AnotherDef := MODULE(x)
+  EXPORT INTEGER a := c * 3;
+  EXPORT INTEGER b := 2;
+  SHARED VIRTUAL INTEGER c := 3; //this def is VIRTUAL
+  EXPORT VIRTUAL INTEGER d := c + 3; //this def is VIRTUAL
+  EXPORT VIRTUAL INTEGER e := c + 3; //this def is VIRTUAL
+END;</programlisting>
 
-  <para>See Also: <link linkend="EXPORT">EXPORT</link>, <link
-  linkend="Attribute_Visibility">Attribute Visibility</link>, <link
-  linkend="MODULE_Structure">MODULE</link></para>
+  <para>See Also: <link linkend="IMPORT">IMPORT</link>, <link
+  linkend="EXPORT">EXPORT</link>, <link
+  linkend="Attribute_Visibility">Definition Visibility</link>, <link
+  linkend="MODULE_Structure">MODULE Structure</link></para>
 </sect1>

docs/ECLLanguageReference/ECLR_mods/SpecStruc-Interface.xml

@@ -57,10 +57,10 @@
           <entry>Definitions, which may be EXPORTed or SHARED. These may be
           similar to fields defined in a RECORD structure where only the type
           and name are defined—the expression that defines the value may be
-          left off (except in some cases where the expression defines the type
-          of attribute, like TRANSFORM structures). If no default value is
-          defined for a <emphasis>member</emphasis>, any MODULE derived from
-          the INTERFACE must define a value for that
+          left off (except in some cases where the expression itself defines
+          the type of definition, like TRANSFORM structures). If no default
+          value is defined for a <emphasis>member</emphasis>, any MODULE
+          derived from the INTERFACE must define a value for that
           <emphasis>member</emphasis> before that MODULE can be used. These
           may not include other INTERFACE or abstract MODULE
           structures.</entry>
@@ -74,7 +74,7 @@
   as a single parameter to complex queries, instead of passing each attribute
   individually. It is similar to a MODULE structure with the VIRTUAL option,
   except errors are given for private (not SHARED or EXPORTed)
-  <emphasis>member</emphasis> attributes.</para>
+  <emphasis>member</emphasis> definitions.</para>
 
   <para>An INTERFACE is an abstract structure—a concrete instance must be
   defined before it can be used in a query. A MODULE structure that inherits

docs/ECLLanguageReference/ECLR_mods/SpecStruc-Module.xml

@@ -19,7 +19,7 @@
   role="bold">) ]</emphasis><emphasis role="bold">
   </emphasis><emphasis></emphasis></para>
 
-  <para><emphasis>attributes;</emphasis></para>
+  <para><emphasis>members;</emphasis></para>
 
   <para><emphasis></emphasis><emphasis role="bold">END;</emphasis></para>
 
@@ -33,14 +33,14 @@
         <row>
           <entry><emphasis>modulename</emphasis></entry>
 
-          <entry>The ECL attribute name of the module.</entry>
+          <entry>The ECL definition name of the module.</entry>
         </row>
 
         <row>
           <entry><emphasis>parameters</emphasis></entry>
 
           <entry>Optional. The parameters to make available to all the
-          <emphasis>attributes</emphasis>.</entry>
+          <emphasis>definitions</emphasis>.</entry>
         </row>
 
         <row>
@@ -48,19 +48,19 @@
 
           <entry>A comma-delimited list of INTERFACE or abstract MODULE
           structures on which to base this instance. The current instance
-          inherits all the <emphasis>attributes</emphasis> from the base
+          inherits all the <emphasis>members</emphasis> from the base
           structures. This may not be a passed parameter.</entry>
         </row>
 
         <row>
-          <entry><emphasis>attributes</emphasis></entry>
-
-          <entry>The attribute definitions that comprise the module. These
-          attributes may receive parameters, may include actions (such as
-          OUTPUT), and may use the EXPORT or SHARED scope types. These may not
-          include INTERFACE or abstract MODULEs (see below). If the LIBRARY
-          option is specified, the <emphasis>attributes</emphasis> must
-          exactly implement the EXPORTed members of the
+          <entry><emphasis>members</emphasis></entry>
+
+          <entry>The definitions that comprise the module. These definitions
+          may receive parameters, may include actions (such as OUTPUT), and
+          may use the EXPORT or SHARED scope types. These may not include
+          INTERFACE or abstract MODULEs (see below). If the LIBRARY option is
+          specified, the <emphasis>definitions</emphasis> must exactly
+          implement the EXPORTed members of the
           <emphasis>interface</emphasis>.</entry>
         </row>
 
@@ -68,7 +68,7 @@
           <entry><emphasis role="bold">VIRTUAL</emphasis></entry>
 
           <entry>Optional. Specifies the MODULE defines an abstract interface
-          whose <emphasis>attributes</emphasis> do not require values to be
+          whose <emphasis>definitions</emphasis> do not require values to be
           defined for them.</entry>
         </row>
 
@@ -95,37 +95,45 @@
   </informaltable>
 
   <para>The <emphasis role="bold">MODULE </emphasis>structure is a container
-  that allows you to group related attributes. The
+  that allows you to group related definitions. The
   <emphasis>parameters</emphasis> passed to the MODULE are shared by all the
-  related <emphasis>attribute </emphasis>definitions. This is similar to the
+  related <emphasis>members </emphasis>definitions. This is similar to the
   FUNCTION structure except that there is no RETURN.</para>
 
   <sect2 id="Attribute_Visibility_Rules">
-    <title>Attribute Visibility<indexterm>
-        <primary>Attribute Visibility</primary>
+    <title>Definition Visibility<indexterm>
+        <primary>Definition Visibility</primary>
       </indexterm> Rules</title>
 
-    <para>The scoping rules for the <emphasis>attributes</emphasis> are the
-    same as those previously described in the <emphasis role="bold">Attribute
+    <para>The scoping rules for the <emphasis>members</emphasis> are the same
+    as those previously described in the <emphasis role="bold">Definition
     Visibility</emphasis> discussion:</para>
 
-    <para>Local attributes are visible only through the next EXPORT or SHARED
-    attribute.</para>
-
-    <para>SHARED attributes are visible only within the MODULE
-    structure.</para>
-
-    <para>EXPORT attributes are visible within the MODULE structure and
-    outside of it.</para>
-
-    <para>Any EXPORT <emphasis>attributes</emphasis> may be referenced using
-    an additional level of standard object.property syntax. For example,
-    assuming the EXPORT MyModuleStructure MODULE structure is contained in an
-    ECL Repository module named MyModule and that it contains an EXPORT
-    <emphasis>attribute</emphasis> named MyAttribute, you would reference that
-    <emphasis>attribute</emphasis> as:</para>
-
-    <para>MyModule.MyModuleStructure.MyAttribute</para>
+    <itemizedlist>
+      <listitem>
+        <para>Local definitions are visible only through the next EXPORT or
+        SHARED definition.</para>
+      </listitem>
+
+      <listitem>
+        <para>SHARED definitions are visible only within the MODULE
+        structure.</para>
+      </listitem>
+
+      <listitem>
+        <para>EXPORT definitions are visible within the MODULE structure and
+        outside of it.</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>Any EXPORT <emphasis>members</emphasis> may be referenced using an
+    additional level of standard object.property syntax. For example, assuming
+    the EXPORT MyModuleStructure MODULE structure is contained in an ECL
+    Repository module named MyModule and that it contains an EXPORT
+    <emphasis>member</emphasis> named MyDefinition, you would reference that
+    <emphasis>definition</emphasis> as:</para>
+
+    <para><programlisting>MyModule.MyModuleStructure.MyDefinition</programlisting></para>
   </sect2>
 
   <sect2 id="Side-Effect_Actions">
@@ -133,43 +141,67 @@
 
     <para>Actions contained in the MODULE have the following semantics:</para>
 
-    <para>1) Any action immediately preceding an
-    <emphasis>attribute</emphasis> is added as a side-effect of that
-    <emphasis>attribute</emphasis>.</para>
-
-    <para>2) Actions cannot precede the following structured attribute types:
-    TRANSFORM, RECORD, MODULE, TYPE, and MACRO.</para>
-
-    <para>3) Generally the action will be executed once if the attribute is
-    used. Where attributes are used in a conditional context (for example,
-    inside PERSISTed attributes or conditional actions) they may be executed
-    more than once.</para>
+    <itemizedlist>
+      <listitem>
+        <para>Any action immediately preceding a
+        <emphasis>definition</emphasis> is added as a side-effect of that
+        <emphasis>definition</emphasis>.</para>
+      </listitem>
+
+      <listitem>
+        <para>Actions cannot precede the following structured definition
+        types: TRANSFORM, RECORD, MODULE, TYPE, and MACRO.</para>
+      </listitem>
+
+      <listitem>
+        <para>Generally the action will be executed once if the definition is
+        used. Where definitions are used in a conditional context (for
+        example, inside PERSISTed definitions or conditional actions) they may
+        be executed more than once.</para>
+      </listitem>
+    </itemizedlist>
   </sect2>
 
   <sect2 id="Concrete_vs_Abstract_Modules">
-    <title>Concrete vs. Abstract Modules</title>
-
-    <para>An abstract MODULE is one that contains at least one pure member
-    <emphasis>attribute</emphasis> (an attribute with no value definition). In
-    order to contain pure member <emphasis>attributes</emphasis>, a MODULE
-    must either be defined as VIRTUAL, or <emphasis>inherit</emphasis> an
-    INTERFACE or another MODULE that is abstract. A concrete MODULE has a
-    value defined for each of its member <emphasis>attributes,
-    </emphasis>whether that value definition is contained in the current
-    instance or is <emphasis>inherited</emphasis>.</para>
-
-    <para>All EXPORTed and SHARED member <emphasis>attributes</emphasis> of an
+    <title>Concrete vs. Abstract (VIRTUAL) Modules</title>
+
+    <para>A MODULE may contain a mixture of VIRTUAL and non-VIRTUAL
+    <emphasis>members</emphasis>. The rules are:</para>
+
+    <itemizedlist>
+      <listitem>
+        <para>ALL <emphasis>members</emphasis> are VIRTUAL if the MODULE has
+        the VIRTUAL option or is an INTERFACE</para>
+      </listitem>
+
+      <listitem>
+        <para>A <emphasis>member</emphasis> is VIRTUAL if it is declared using
+        the EXPORT VIRTUAL or SHARED VIRTUAL keywords</para>
+      </listitem>
+
+      <listitem>
+        <para>A <emphasis>member</emphasis> is VIRTUAL if the definition of
+        the same name in the <emphasis>inherited</emphasis> module is
+        VIRTUAL.</para>
+      </listitem>
+
+      <listitem>
+        <para>Some <emphasis>members</emphasis> can never be virtual – RECORD
+        structures.</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>All EXPORTed and SHARED <emphasis>members</emphasis> of an
     <emphasis>inherited</emphasis> abstract module can be overridden by
     re-defining them in the current instance, whether that current instance is
-    abstract or concrete. Overridden attributes must exactly match the type
-    and parameters of the <emphasis>inherited</emphasis> member
-    <emphasis>attributes</emphasis>. Multiple <emphasis>inherited
-    </emphasis>interfaces may contain attributes with the same name if they
+    abstract or concrete. Overridden definitions must exactly match the type
+    and parameters of the <emphasis>inherited</emphasis>
+    <emphasis>members</emphasis>. Multiple <emphasis>inherited
+    </emphasis>interfaces may contain definitions with the same name if they
     are the same type and receive the same parameters, but if those
-    <emphasis>inherited</emphasis> member <emphasis>attributes</emphasis> have
-    different values defined for them, the conflict must be resolved by
-    overriding that <emphasis>attribute </emphasis>in the current
-    instance.</para>
+    <emphasis>inherited</emphasis> <emphasis>members</emphasis> have different
+    values defined for them, the conflict must be resolved by overriding that
+    <emphasis>member </emphasis>in the current instance.</para>
   </sect2>
 
   <sect2 id="LIBRARY_Modules">
@@ -180,35 +212,60 @@
     action discussions). There are several restrictions on what may be
     included in a query library. They are:</para>
 
-    <para>It may not contain side-effect actions (like OUTPUT or BUILD)</para>
+    <itemizedlist>
+      <listitem>
+        <para>It may not contain side-effect actions (like OUTPUT or
+        BUILD)</para>
+      </listitem>
 
-    <para>It may not contain attributes with workflow services attached to
-    them(such as PERSIST, STORED, SUCCESS, etc.)</para>
+      <listitem>
+        <para>It may not contain definitions with workflow services attached
+        to them (such as PERSIST, STORED, SUCCESS, etc.)</para>
+      </listitem>
+    </itemizedlist>
 
     <para>It may only EXPORT:</para>
 
-    <para>dataset/recordset attributes</para>
+    <itemizedlist>
+      <listitem>
+        <para>Dataset/recordset definitions</para>
+      </listitem>
 
-    <para>datarow attributes (such as the ROW function<indexterm>
-        <primary>ROW function</primary>
-      </indexterm>)</para>
+      <listitem>
+        <para>Datarow definitions (such as the ROW function<indexterm>
+            <primary>ROW function</primary>
+          </indexterm>)</para>
+      </listitem>
 
-    <para>single-valued and Boolean attributes</para>
+      <listitem>
+        <para>Single-valued and Boolean definitions</para>
+      </listitem>
+    </itemizedlist>
 
     <para>And may NOT export:</para>
 
-    <para>actions (like OUTPUT or BUILD)</para>
+    <itemizedlist>
+      <listitem>
+        <para>Actions (like OUTPUT or BUILD)</para>
+      </listitem>
 
-    <para>TRANSFORM functions</para>
+      <listitem>
+        <para>TRANSFORM functions</para>
+      </listitem>
 
-    <para>other MODULE structures</para>
+      <listitem>
+        <para>Other MODULE structures</para>
+      </listitem>
 
-    <para>MACRO attributes</para>
+      <listitem>
+        <para>MACRO definitions</para>
+      </listitem>
+    </itemizedlist>
 
     <para>Example:</para>
 
     <programlisting>EXPORT filterDataset(STRING search, BOOLEAN onlyOldies) := MODULE
-  f := namesTable; //local to the “g” attribute
+  f := namesTable; //local to the “g” definition
   SHARED g := IF (onlyOldies, f(age &gt;= 65), f);
           //SHARED = visible only within the structure
   EXPORT included := g(surname != search);
@@ -244,21 +301,26 @@ BOOLEAN doIt := TRUE : STORED('doIt');
 IF (doIt, OUTPUT(customerNames.File));
           
 //VIRTUAL examples
-Mod1 := MODULE,VIRTUAL //an abstract module
+Mod1 := MODULE,VIRTUAL //a fully abstract module
   EXPORT val := 1;
   EXPORT func(INTEGER sc) := val * sc;
 END;
          
-Mod2 := MODULE(Mod1) //a concete instance
-  EXPORT val := 3; //override inherited default value
-END
+Mod2 := MODULE(Mod1) //instance
+  EXPORT val := 3; //a concete member, overriding default value
+                   //while func remains abstract
+END;
      
-Mod3 := MODULE(Mod1) //a concete instance
-  EXPORT func(INTEGER sc) := val + sc; //override inherited func
-END
+Mod3 := MODULE(Mod1) //a fully concete instance
+  EXPORT func(INTEGER sc) := val + sc; //overrides inherited func
+END;
 OUTPUT(Mod2.func(5)); //result is 15
 OUTPUT(Mod3.func(5)); //result is 6</programlisting>
 
-    <para>See Also: <link linkend="FUNCTION_Structure">FUNCTION Structure</link>, <link linkend="Attribute_Visibility">Attribute Visibility</link>, <link linkend="INTERFACE_Structure">INTERFACE Structure</link>, <link linkend="LIBRARY">LIBRARY</link>, <link linkend="BUILD">BUILD</link></para>
+    <para>See Also: <link linkend="FUNCTION_Structure">FUNCTION
+    Structure</link>, <link linkend="Attribute_Visibility">Definition
+    Visibility</link>, <link linkend="INTERFACE_Structure">INTERFACE
+    Structure</link>, <link linkend="LIBRARY">LIBRARY</link>, <link
+    linkend="BUILD">BUILD</link></para>
   </sect2>
 </sect1>