Commits

Jeroen Ruigrok van der Werven committed fc44431

Use command, not productname, the latter adds trademark glyphs, which are
unnecessary.

Comments (0)

Files changed (2)

doc/calculus/calculus.xml

   <chapter id="introduction">
     <title>Introduction</title>
   
-    <para>This document describes a tool, <productname>calculus</productname>,
+    <para>This document describes a tool, <command>calculus</command>,
       which allows complex type systems to be described in a simple algebraic
       format, and transforms this into a system of C types which implements
       this algebra.</para>
   
-    <para><productname>calculus</productname> was initially written as a
+    <para><command>calculus</command> was initially written as a
       design tool for use with the TenDRA C and C++ producers. The producers'
       internal datatypes reflect the highly complex interdependencies between
       the C and C++ language concepts (types, expressions and so on) which
     <sect1 id="Options">
       <title>1.1. Using calculus</title>
   
-      <para>The general form for invoking <productname>calculus</productname>
+      <para>The general form for invoking <command>calculus</command>
         is as follows:
         <command>calculus<optional><option>options</option></optional>
         <option>input</option> ....
         described in the following section.</para>
   
       <para>Note that it is necessary to check any program written using
-        <productname>calculus</productname> against the <code>#pragma
+        <command>calculus</command> against the <code>#pragma
         token</code> version of the specification in order to get the full
         benefits of the rigorous type checking provided by the tool. Some
         sections of the program (if only the <link linkend="COutputSupport">basic
     <sect1 id="Example">
       <title>1.2. Example program</title>
 
-      <para>The program <productname>calculus</productname> itself was written
+      <para>The program <command>calculus</command> itself was written
         using a type system specified using the
-        <productname>calculus</productname> tool. It is designed to provide an
+        <command>calculus</command> tool. It is designed to provide an
         example of its own application, with some features not strictly
         necessary for the functionality of the program being added for
         illustrative purposes.</para>
       <title>2.7. Relations between algebras</title>
   
       <para>As <link linkend="Options">mentioned above</link>, more than one input
-        algebra may be specified to <productname>calculus</productname>. Each
+        algebra may be specified to <command>calculus</command>. Each
         is processed separately, and output is generated for only one. By
         default this is the last algebra processed, however a specific algebra
         can be specified using the command-line option
     <title>Output type system specification</title>
   
     <para>In this section we document the basic output of
-      <productname>calculus</productname>. Two forms of the output can be
+      <command>calculus</command>. Two forms of the output can be
       generated - a description of the output specification in terms of the
       TenDRA <code>#pragma token</code> constructs, and the actual C code
       which implements these tokens.</para>
         type <i>t</i> respectively. (It is possible to suppress all constructs
         involving <code>VEC</code> or <code>VEC_PTR</code> by passing the
         <code>-x</code> command-line option to
-        <productname>calculus</productname>. Similarly <code>STACK</code>
+        <command>calculus</command>. Similarly <code>STACK</code>
         constructs may be suppressed using <code>-z</code>.)</para>
   
       <para>These constructors can be applied to any type, although in
       </programlisting>needs to be defined.</para>
   
       <para>Examples of these support routines can be found in the
-        <link linkend="Example"><productname>calculus</productname> program</link>
+        <link linkend="Example"><command>calculus</command> program</link>
         itself.</para>
     </sect1>
 
       <title>4.3. Run-time checking</title>
   
       <para>The type checking facilities supported by
-        <productname>calculus</productname> allow for compile-time detection
+        <command>calculus</command> allow for compile-time detection
         of many potential programming errors, however there are many problems,
         such as dereferencing null pointers, deconstructing empty lists and
         union tag errors which can only be detected at run-time. For this
-        reason <productname>calculus</productname> can be made to add extra
+        reason <command>calculus</command> can be made to add extra
         assertions to check for such errors into its output. This is done by
         specifying the <code>-a</code> command-line option.</para>
   
     <para>The disk reading and writing routines are output into the files
       <filename>read_def.h</filename> and <filename>write_def.h</filename>
       respectively if the <option>-d</option> command-line option is passed to
-      <productname>calculus</productname>. The object printing routines are
+      <command>calculus</command>. The object printing routines are
       output if the <option>-p</option> option is given, with additional code
       designed for use with run-time debuggers being added if the
       <option>-a</option> option is also given.</para>
   
       <para>One application of these object printing routines is to aid
         debugging programs written using the
-        <productname>calculus</productname> tool.  The form of the type system
+        <command>calculus</command> tool.  The form of the type system
         implementation means that it is not easy to extract information using
         run-time debuggers without a detailed knowledge of the structure of
         this implementation. As a more convenient alternative, if both the
         <code>-p</code> and <code>-a</code> command-line options are given
-        then <productname>calculus</productname> will generate
+        then <command>calculus</command> will generate
         functions:
         <programlisting>
           void DEBUG_<i>type</i> ( <i>t</i> ) ;
       <para>An important feature of the disk reading and writing routines,
         namely aliasing, has been mentioned but not yet described. The problem
         to be faced is that many of the objects built up using type systems
-        defined using <productname>calculus</productname> will be cyclic -
+        defined using <command>calculus</command> will be cyclic -
         they will include references to themselves in their own definitions.
         Aliasing is a mechanism for breaking such cycles by ensuring that only
         one copy of an object is ever written to disk, or that only one copy
         giving the next alias number to be assigned, and routines for adding
         an alias to the list of all aliases, and looking up an alias in this
         list. Example implementations of these routines are given in the
-        <link linkend="Example"><productname>calculus</productname> program</link>
+        <link linkend="Example"><command>calculus</command> program</link>
         itself.</para>
     </sect1>
 
       <title>5.5. Application to calculus</title>
   
       <para>As <link linkend="Example">mentioned above</link>, the
-        <productname>calculus</productname> program itself is an example of
+        <command>calculus</command> program itself is an example of
         its own application. It therefore contains routines for reading and
         writing a representation of an algebra to and from disk, and for
         pretty-printing the contents of an algebra. These may be accessed
         above.</para>
   
       <para>If the <option>-w</option> command-line option is specified to
-        <productname>calculus</productname> then it reads its input file,
+        <command>calculus</command> then it reads its input file,
         <i>input</i>, as normal, but writes a disk representation of the input
         algebra to <i>output</i>, which in this instance is an output file,
         rather than an output directory. An output file produced in this way
         can then be specified as an input file to
-        <productname>calculus</productname> if the <option>-r</option> option
+        <command>calculus</command> if the <option>-r</option> option
         is given.  Finally the input algebra may be pretty-printed to an
         output file (or the standard output if no <i>output</i> argument is
         given) by specifying the <option>-o</option> option.</para>
   <chapter>
     <title>Template files</title>
   
-    <para>It is possible to use <productname>calculus</productname> to
+    <para>It is possible to use <command>calculus</command> to
       generate an output file from a template input file, <i>template</i>,
       using the syntax:
       <programlisting>
       </programlisting>
       The template file consists of a list of either template directives or
       source lines containing escape sequences which are expanded by
-      <productname>calculus</productname>. Template directive lines are
+      <command>calculus</command>. Template directive lines are
       distinguished by having <code>@</code> as their first character.  Escape
       sequences consist of <code>%</code> following by one or more
       characters.</para>
   
     <para>A number of escape sequences can be used anywhere.  <code>%ZX</code>
       and <code>%ZV</code> give the name and version number of the version of
-      <productname>calculus</productname> used.  <code>%Z</code> and
+      <command>calculus</command> used.  <code>%Z</code> and
       <code>%V</code> give the name and version number of the input algebra.
       <code>%%</code> and <code>%@</code> give <code>%</code> and
       <code>@</code> respectively, and <code>%</code> as the last character in

doc/tspec/tspec.xml

     
       <para>In this document we address the problem of how to translate a
         standard API specification into its TDF representation, by describing
-        a tool, <productname>tspec</productname>, which has been developed for
+        a tool, <command>tspec</command>, which has been developed for
         this purpose.</para>
     
       <para>The low level form which is used to represent APIs to the C to TDF
         necessarily complex, and can only be checked through extensive testing
         using the producer. Instead an alternative form, close to C, has been
         developed for this purpose. API specifications in this form are
-        transformed by <productname>tspec</productname> into the corresponding
+        transformed by <command>tspec</command> into the corresponding
         <code>#pragma token</code> statements, while it applies various
         internal checks to the API description.</para>
     
         it directly to the <code>#pragma token</code> syntax could require
         periodic reworkings. Improvements in the <code>#pragma token</code>
         syntax will be reflected in the translations produced by future
-        versions of <productname>tspec</productname>.</para>
+        versions of <command>tspec</command>.</para>
     
       <para>The <code>tspec</code> syntax is not designed to be a formal
         specification language. Instead it is a pragmatic attempt to capture
         <title>2.1. Specification Levels</title>
     
         <para>Let us begin by examining the various levels of specification
-          with which <productname>tspec</productname> is concerned. At the
+          with which <command>tspec</command> is concerned. At the
           lowest level it is concerned with objects - the types, expressions,
           constants etc.  which comprise the API - and indeed most of this
-          document is concerned with how <productname>tspec</productname>
+          document is concerned with how <command>tspec</command>
           describes these objects. At the highest level,
-          <productname>tspec</productname> is concerned with APIs. We could
+          <command>tspec</command> is concerned with APIs. We could
           just describe an API as being a set of objects, however this is to
           ignore the internal structure of APIs.</para>
       
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.