Deploying to gh-pages from @ d90d748 🚀

Author: Fortran

pr/477/.doctrees/environment.pickle

@@ -310,7 +310,7 @@ this is that in code like
 slq = slp // slq
 ```
 
-\ -- with the overloaded concatenation operator meaning that the argument
+-- with the overloaded concatenation operator meaning that the argument
 lists are joined -- multiple deep copies need to be done (the
 implementation of the module procedure `join_lists` that supplies the
 necessary specific for `//` is not shown here; see the source

pr/477/.doctrees/learn/oop_features_in_fortran/object_based_programming_techniques.doctree

@@ -65,7 +65,7 @@ end type
 An object of this type
 
 ```f90
-TYPE(charged_body) :: a_proton
+type(charged_body) :: a_proton
 ```
 
 would then have the following type components:
@@ -344,7 +344,7 @@ end module
   extension is used on a larger scale, setting or modifying further
   components in the conventional way becomes rather irksome without a
   concept like that above, especially if
-  [type-bound procedures](#sec:tbp)
+  _type-bound procedures_
   with a simple _and_ uniform interface must be implemented;
 - The object `a_wtype` remains unchanged in case an unsuitable value is
   provided for `a_component`. One could add explicit error handling, but
@@ -385,7 +385,7 @@ call setup_wtype(my_wtype, c_nz)
 call setup_wtype(my_wtype, c_w)
 ```
 
-## Type-bound procedures (TBP) {#sec:tbp}
+## Type-bound procedures (TBP)
 
 To resolve the class mismatch issues arising from the use of polymorphic
 objects, one needs a language mechanism for making a run-time decision
@@ -546,7 +546,7 @@ call my_polymorphic_body%update(dp)
 
 The `sortable` type used for demonstrating the `sortable_list`
 functionality in the
-[object-based chapter's](#sec:oop_techniques)
+_object-based chapter's_
 example was set up as a fixed container-like type. It is desirable to be
 able to use the list machinery more flexibly i.e., for any type that
 supports the "less-than" comparison. This can be achieved by introducing
@@ -610,9 +610,9 @@ programming technique, which is also known as **dependency inversion**
    end type
    ```
 
-The advantage of this is that no change to the preexisting machinery
-will be needed whenever a programmer decides to add an extension type
-as outlined in 2. below.
+   The advantage of this is that no change to the preexisting machinery
+   will be needed whenever a programmer decides to add an extension type
+   as outlined in 2. below.
 
 2. For a concrete realization of a `sortable` object, the programmer
    needs to create a type extension, for example
@@ -625,10 +625,10 @@ as outlined in 2. below.
    end type
    ```
 
-including an _obligatory_ implementation `less_than_string` of an
-overriding TBP for the deferred binding. The constructor function
-(promised earlier, but not yet delivered) also needs to be updated to
-enable creation of objects of the extended type.
+   including an _obligatory_ implementation `less_than_string` of an
+   overriding TBP for the deferred binding. The constructor function
+   (promised earlier, but not yet delivered) also needs to be updated to
+   enable creation of objects of the extended type.
 
 ## Generic type-bound procedures and operator overloading
 
@@ -664,7 +664,7 @@ will automatically select the overridden procedure.
 Named generic type-bound procedures that do not overload existing
 operations can also be defined; an example for this is given in the
 section
-"[Functions with parameters](#sec:functions_with_parameters)".
+_Functions with parameters_.
 The rules for generic resolution work similar as for nonpolymorphic
 generic procedure interfaces, with the additional restriction that
 polymorphic dummy arguments that are related by inheritance cannot be

pr/477/.doctrees/learn/oop_features_in_fortran/object_oriented_programming_techniques.doctree

@@ -1,6 +1,6 @@
 # Performance and ease of use
 
-## Functions with parameters {#sec:functions_with_parameters}
+## Functions with parameters
 
 ### A type definition for invocation of a general function
 
@@ -271,7 +271,7 @@ feature is recommended against.
 Returning to our earlier example type body, the next idea would be to
 simulate the dynamics of a large ensemble of bodies. A procedure
 
-```f90
+```
 subroutine propagate(bodies, delta_t, force_field)
   type(body), intent(inout) :: bodies(:)
   real, intent(in) :: delta_t

pr/477/.doctrees/learn/oop_features_in_fortran/performance_and_ease_of_use.doctree

@@ -970,7 +970,7 @@ <h2>Copying objects of container-like type<a class="headerlink" href="#copying-o
 <div class="highlight-f90 notranslate"><div class="highlight"><pre><span></span><span class="n">slq</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">slp</span><span class="w"> </span><span class="o">//</span><span class="w"> </span><span class="n">slq</span>
 </pre></div>
 </div>
-<p>\ – with the overloaded concatenation operator meaning that the argument
+<p>– with the overloaded concatenation operator meaning that the argument
 lists are joined – multiple deep copies need to be done (the
 implementation of the module procedure <code class="docutils literal notranslate"><span class="pre">join_lists</span></code> that supplies the
 necessary specific for <code class="docutils literal notranslate"><span class="pre">//</span></code> is not shown here; see the source

pr/477/_sources/learn/oop_features_in_fortran/object_based_programming_techniques.md.txt

@@ -760,7 +760,7 @@ <h2>Extension types<a class="headerlink" href="#extension-types" title="Link to
 </pre></div>
 </div>
 <p>An object of this type</p>
-<div class="highlight-f90 notranslate"><div class="highlight"><pre><span></span><span class="k">TYPE</span><span class="p">(</span><span class="n">charged_body</span><span class="p">)</span><span class="w"> </span><span class="kd">::</span><span class="w"> </span><span class="n">a_proton</span>
+<div class="highlight-f90 notranslate"><div class="highlight"><pre><span></span><span class="k">type</span><span class="p">(</span><span class="n">charged_body</span><span class="p">)</span><span class="w"> </span><span class="kd">::</span><span class="w"> </span><span class="n">a_proton</span>
 </pre></div>
 </div>
 <p>would then have the following type components:</p>
@@ -1018,7 +1018,7 @@ <h3>Unlimited polymorphic objects<a class="headerlink" href="#unlimited-polymorp
 extension is used on a larger scale, setting or modifying further
 components in the conventional way becomes rather irksome without a
 concept like that above, especially if
-<a class="reference internal" href="#sec:tbp"><span class="xref myst">type-bound procedures</span></a>
+<em>type-bound procedures</em>
 with a simple <em>and</em> uniform interface must be implemented;</p></li>
 <li><p>The object <code class="docutils literal notranslate"><span class="pre">a_wtype</span></code> remains unchanged in case an unsuitable value is
 provided for <code class="docutils literal notranslate"><span class="pre">a_component</span></code>. One could add explicit error handling, but
@@ -1059,8 +1059,8 @@ <h3>Unlimited polymorphic objects<a class="headerlink" href="#unlimited-polymorp
 </div>
 </section>
 </section>
-<section id="type-bound-procedures-tbp-sec-tbp">
-<h2>Type-bound procedures (TBP) {#sec:tbp}<a class="headerlink" href="#type-bound-procedures-tbp-sec-tbp" title="Link to this heading">#</a></h2>
+<section id="type-bound-procedures-tbp">
+<h2>Type-bound procedures (TBP)<a class="headerlink" href="#type-bound-procedures-tbp" title="Link to this heading">#</a></h2>
 <p>To resolve the class mismatch issues arising from the use of polymorphic
 objects, one needs a language mechanism for making a run-time decision
 on a procedure invocation that depends on the dynamic type of a
@@ -1206,7 +1206,7 @@ <h2>Type-bound procedures (TBP) {#sec:tbp}<a class="headerlink" href="#type-boun
 <h2>Abstract types and interfaces<a class="headerlink" href="#abstract-types-and-interfaces" title="Link to this heading">#</a></h2>
 <p>The <code class="docutils literal notranslate"><span class="pre">sortable</span></code> type used for demonstrating the <code class="docutils literal notranslate"><span class="pre">sortable_list</span></code>
 functionality in the
-<a class="reference internal" href="#sec:oop_techniques"><span class="xref myst">object-based chapter’s</span></a>
+<em>object-based chapter’s</em>
 example was set up as a fixed container-like type. It is desirable to be
 able to use the list machinery more flexibly i.e., for any type that
 supports the “less-than” comparison. This can be achieved by introducing
@@ -1261,12 +1261,10 @@ <h2>Abstract types and interfaces<a class="headerlink" href="#abstract-types-and
 <span class="k">end type</span>
 </pre></div>
 </div>
-</li>
-</ol>
 <p>The advantage of this is that no change to the preexisting machinery
 will be needed whenever a programmer decides to add an extension type
 as outlined in 2. below.</p>
-<ol class="arabic" start="2">
+</li>
 <li><p>For a concrete realization of a <code class="docutils literal notranslate"><span class="pre">sortable</span></code> object, the programmer
 needs to create a type extension, for example</p>
 <div class="highlight-f90 notranslate"><div class="highlight"><pre><span></span><span class="k">type</span><span class="p">,</span><span class="w"> </span><span class="k">public</span><span class="p">,</span><span class="w"> </span><span class="k">extends</span><span class="p">(</span><span class="n">sortable</span><span class="p">)</span><span class="w"> </span><span class="kd">::</span><span class="w"> </span><span class="n">sortable_string</span>
@@ -1276,12 +1274,12 @@ <h2>Abstract types and interfaces<a class="headerlink" href="#abstract-types-and
 <span class="k">end type</span>
 </pre></div>
 </div>
-</li>
-</ol>
 <p>including an <em>obligatory</em> implementation <code class="docutils literal notranslate"><span class="pre">less_than_string</span></code> of an
 overriding TBP for the deferred binding. The constructor function
 (promised earlier, but not yet delivered) also needs to be updated to
 enable creation of objects of the extended type.</p>
+</li>
+</ol>
 </section>
 <section id="generic-type-bound-procedures-and-operator-overloading">
 <h2>Generic type-bound procedures and operator overloading<a class="headerlink" href="#generic-type-bound-procedures-and-operator-overloading" title="Link to this heading">#</a></h2>
@@ -1312,7 +1310,7 @@ <h2>Generic type-bound procedures and operator overloading<a class="headerlink"
 <p>Named generic type-bound procedures that do not overload existing
 operations can also be defined; an example for this is given in the
 section
-“<a class="reference internal" href="#sec:functions_with_parameters"><span class="xref myst">Functions with parameters</span></a>”.
+<em>Functions with parameters</em>.
 The rules for generic resolution work similar as for nonpolymorphic
 generic procedure interfaces, with the additional restriction that
 polymorphic dummy arguments that are related by inheritance cannot be
@@ -1472,7 +1470,7 @@ <h3>Diagramming the dependencies between program units<a class="headerlink" href
 <li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#unlimited-polymorphic-objects">Unlimited polymorphic objects</a></li>
 </ul>
 </li>
-<li class="toc-h2 nav-item toc-entry"><a class="reference internal nav-link" href="#type-bound-procedures-tbp-sec-tbp">Type-bound procedures (TBP) {#sec:tbp}</a></li>
+<li class="toc-h2 nav-item toc-entry"><a class="reference internal nav-link" href="#type-bound-procedures-tbp">Type-bound procedures (TBP)</a></li>
 <li class="toc-h2 nav-item toc-entry"><a class="reference internal nav-link" href="#abstract-types-and-interfaces">Abstract types and interfaces</a></li>
 <li class="toc-h2 nav-item toc-entry"><a class="reference internal nav-link" href="#generic-type-bound-procedures-and-operator-overloading">Generic type-bound procedures and operator overloading</a></li>
 <li class="toc-h2 nav-item toc-entry"><a class="reference internal nav-link" href="#completing-the-dependency-inversion">Completing the dependency inversion</a><ul class="nav section-nav flex-column">

pr/477/_sources/learn/oop_features_in_fortran/object_oriented_programming_techniques.md.txt

@@ -705,8 +705,8 @@ <h3>
                 <article class="bd-article">
                    <section class="tex2jax_ignore mathjax_ignore" id="performance-and-ease-of-use">
 <h1>Performance and ease of use<a class="headerlink" href="#performance-and-ease-of-use" title="Link to this heading">#</a></h1>
-<section id="functions-with-parameters-sec-functions-with-parameters">
-<h2>Functions with parameters {#sec:functions_with_parameters}<a class="headerlink" href="#functions-with-parameters-sec-functions-with-parameters" title="Link to this heading">#</a></h2>
+<section id="functions-with-parameters">
+<h2>Functions with parameters<a class="headerlink" href="#functions-with-parameters" title="Link to this heading">#</a></h2>
 <section id="a-type-definition-for-invocation-of-a-general-function">
 <h3>A type definition for invocation of a general function<a class="headerlink" href="#a-type-definition-for-invocation-of-a-general-function" title="Link to this heading">#</a></h3>
 <p>In scientific applications, a commonly occurring requirement is the need
@@ -954,12 +954,12 @@ <h3>Using the function type<a class="headerlink" href="#using-the-function-type"
 <h2>Arrays of structures versus structures of arrays<a class="headerlink" href="#arrays-of-structures-versus-structures-of-arrays" title="Link to this heading">#</a></h2>
 <p>Returning to our earlier example type body, the next idea would be to
 simulate the dynamics of a large ensemble of bodies. A procedure</p>
-<div class="highlight-f90 notranslate"><div class="highlight"><pre><span></span><span class="k">subroutine </span><span class="n">propagate</span><span class="p">(</span><span class="n">bodies</span><span class="p">,</span><span class="w"> </span><span class="n">delta_t</span><span class="p">,</span><span class="w"> </span><span class="n">force_field</span><span class="p">)</span>
-<span class="w">  </span><span class="k">type</span><span class="p">(</span><span class="n">body</span><span class="p">),</span><span class="w"> </span><span class="k">intent</span><span class="p">(</span><span class="n">inout</span><span class="p">)</span><span class="w"> </span><span class="kd">::</span><span class="w"> </span><span class="n">bodies</span><span class="p">(:)</span>
-<span class="w">  </span><span class="kt">real</span><span class="p">,</span><span class="w"> </span><span class="k">intent</span><span class="p">(</span><span class="n">in</span><span class="p">)</span><span class="w"> </span><span class="kd">::</span><span class="w"> </span><span class="n">delta_t</span>
-<span class="w">  </span><span class="k">type</span><span class="p">(</span><span class="n">field_type</span><span class="p">),</span><span class="w"> </span><span class="k">intent</span><span class="p">(</span><span class="n">in</span><span class="p">)</span><span class="w"> </span><span class="kd">::</span><span class="w"> </span><span class="n">force_field</span>
-<span class="w">  </span><span class="p">:</span>
-<span class="k">end subroutine</span>
+<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">subroutine</span> <span class="n">propagate</span><span class="p">(</span><span class="n">bodies</span><span class="p">,</span> <span class="n">delta_t</span><span class="p">,</span> <span class="n">force_field</span><span class="p">)</span>
+  <span class="nb">type</span><span class="p">(</span><span class="n">body</span><span class="p">),</span> <span class="n">intent</span><span class="p">(</span><span class="n">inout</span><span class="p">)</span> <span class="p">::</span> <span class="n">bodies</span><span class="p">(:)</span>
+  <span class="n">real</span><span class="p">,</span> <span class="n">intent</span><span class="p">(</span><span class="ow">in</span><span class="p">)</span> <span class="p">::</span> <span class="n">delta_t</span>
+  <span class="nb">type</span><span class="p">(</span><span class="n">field_type</span><span class="p">),</span> <span class="n">intent</span><span class="p">(</span><span class="ow">in</span><span class="p">)</span> <span class="p">::</span> <span class="n">force_field</span>
+  <span class="p">:</span>
+<span class="n">end</span> <span class="n">subroutine</span>
 </pre></div>
 </div>
 <p>might be supplied that modifies the components of all ensemble members,
@@ -1044,7 +1044,7 @@ <h3>Variations on the passed object<a class="headerlink" href="#variations-on-th
 </div>
 
 <nav id="bd-toc-nav" class="page-toc"><ul class="nav section-nav flex-column">
-<li class="toc-h2 nav-item toc-entry"><a class="reference internal nav-link" href="#functions-with-parameters-sec-functions-with-parameters">Functions with parameters {#sec:functions_with_parameters}</a><ul class="nav section-nav flex-column">
+<li class="toc-h2 nav-item toc-entry"><a class="reference internal nav-link" href="#functions-with-parameters">Functions with parameters</a><ul class="nav section-nav flex-column">
 <li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#a-type-definition-for-invocation-of-a-general-function">A type definition for invocation of a general function</a></li>
 <li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#performance-issues-arising-from-object-oriented-programming">Performance issues arising from object-oriented programming</a></li>
 <li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#completing-the-function-type-definition">Completing the function type definition</a></li>