CVS difference for ai12s/ai12-0058-1.txt

Differences between 1.11 and version 1.12
Log of other versions for file ai12s/ai12-0058-1.txt

--- ai12s/ai12-0058-1.txt	2017/04/21 04:17:34	1.11
+++ ai12s/ai12-0058-1.txt	2017/04/25 04:53:04	1.12
@@ -1,4 +1,4 @@
-!standard B.5(10)                                17-04-20   AI12-0058-1/06
+!standard B.5(10)                                17-04-24   AI12-0058-1/07
 !standard B.5(18)
 !standard B.5(21)
 !standard B.5(31)
@@ -36,7 +36,7 @@
 current (2008) Fortran standard.
 
 The declarations "real*n" etc., recommended for use with Fortran 77,
-were never part of any standard.  The implementation-dependent types
+were never part of any standard. The implementation-dependent types
 Real_Kind_n etc., where n is an integer, recommended for use with
 Fortran 90, are not as useful as they could be, because the value of n
 depends upon both the companion Fortran processor, and the options used
@@ -46,18 +46,18 @@
 Fortran provides facilities by which a program can inquire the kind type
 parameter value using the desired precision or range of a floating-point
 number, or the kind type parameter value of an object, using e.g.
-kind(1.0d0).  If an Ada programmer sees declarations in a Fortran
+kind(1.0d0). If an Ada programmer sees declarations in a Fortran
 program unit of the form
 
   integer, parameter :: RK = selected_real_kind(p=6,r=30)
   ! Precision: at least 6 digits; exponent range: at least 30
   real(rk) :: X
 
-the advice to use Real_Kind_n is not useful.  It is not uncommon for
-these declarations to be in different program units.  A Fortran program
+the advice to use Real_Kind_n is not useful. It is not uncommon for
+these declarations to be in different program units. A Fortran program
 frequently has a module where the kind type parameters to be used
 throughout the program are declared, and those parameters are then used,
-by access to that module, throughout the program.  The Ada programmer
+by access to that module, throughout the program. The Ada programmer
 ought to be advised to define a type using
 
   RK: constant := 6;
@@ -67,8 +67,8 @@
 a kind of complex corresponding to each kind of real, with the kind type
 parameter specified in the same way as for real, and having the same
 value as real objects of the same kind as the real and imaginary parts
-of the complex object have.  Annex B.5 supports only single precision
-complex.  The discussion in B.5(21.a) that reminds a programmer that it
+of the complex object have. Annex B.5 supports only single precision
+complex. The discussion in B.5(21.a) that reminds a programmer that it
 is possible to instantiate a complex type corresponding to a Fortran
 complex type and kind using, e.g.,
 
@@ -76,7 +76,7 @@
     new Ada.Numeric.Generic_Complex_Types ( Real_RK );
   type Complex_RK is new Complex_Types_RK.Complex;
 
-etc., should be more explicit, not a footnote.  Since Fortran standards
+etc., should be more explicit, not a footnote. Since Fortran standards
 since 1990 have required at least two kinds of real (single and double
 precision), and a kind of complex for each supported kind of real, it
 would be appropriate for Interfaces.Fortran to include a double
@@ -119,15 +119,15 @@
 
 2. Additional character kinds
 
-The Fortran standard defines a default character set.  It should be
+The Fortran standard defines a default character set. It should be
 remarked that the type Character_Set is compatible with the Fortran
 default character kind.
 
 The Fortran standard requires that the SELECTED_CHAR_KIND intrinsic
 function accept the argument values 'ascii' and 'iso_10646' (without
 regard to case), and return positive values if the processor supports
-those kinds of characters.  The kind 'ascii' corresponds to ISO/IEC
-646:1991.  The kind 'iso_10646' corresponds to UCS-4 as specified in
+those kinds of characters. The kind 'ascii' corresponds to ISO/IEC
+646:1991. The kind 'iso_10646' corresponds to UCS-4 as specified in
 ISO/IEC 10646.
 
 Since 'ascii' and 'iso_10646' kinds are defined by the Fortran standard,
@@ -145,17 +145,17 @@
 reference to Fortran 77 should be removed.
 
 Using constants as kind type parameter values in Fortran 90 should be
-avoided, because the values are processor dependent.  The declarations
+avoided, because the values are processor dependent. The declarations
 Integer(kind=4) and Integer(kind=8) might mean four-byte and eight-byte
 integers on one processor, while a different processor (or the same
 processor with different command-line options) might use Integer(kind=1)
-and Integer(kind=2) for the same objects.  If this material is to be
+and Integer(kind=2) for the same objects. If this material is to be
 retained, it should be made clear that using constants as kind type
 parameter values is not recommended.
 
 It would be better to provide, under "Examples," illustrations of the
 correspondence between Ada types and Fortran types and kinds, at least
-for Integer and Real.  For example, a Fortran type and kind for Real
+for Integer and Real. For example, a Fortran type and kind for Real
 with six digits of precision and unspecified range, would be declared in
 Fortran using
 
@@ -254,7 +254,7 @@
 examples:  e.g., assumed-shape dummy argument
 (formal parameter) arrays (corresponding to integer range <> for one
 dimension), optional arguments (parameters), and the distinction between
-pointer and allocatable variables in Fortran, are completely absent.  A
+pointer and allocatable variables in Fortran, are completely absent. A
 recent ISO Technical Specification (29113), which will be incorporated
 into the next revision of the Fortran standard, specifies how these
 entities are described in C, by defining structs and functions
@@ -277,12 +277,12 @@
 Fortran standard is published.
 
 Object-oriented programming features, modeled on Simula, were added to
-Fortran in the 2003 standard.  These include type extension,
-polymorphism, type-bound procedures, and overriding.  It may be
+Fortran in the 2003 standard. These include type extension,
+polymorphism, type-bound procedures, and overriding. It may be
 desirable, yet difficult, to support this in annex B.5.
 
 Due to this perceived difficulty in designing and describing Ada interfaces to
-these features, the addition of interfaces to object oriented
+these features, the addition of interfaces to object-oriented
 features of Fortran should also be split off as a separate AI, as the decision
 to progress those features should be weighed independently from the main goals
 of this AI, which is mostly to update the existing content of the Fortran
@@ -291,12 +291,12 @@
 Other possible interfaces to Fortran not addressed by this AI include;
 
 -- Use of the Convention aspect for record types to interoperate with
-   Fortran derived types.  Additional sub-issues, for which the
+   Fortran derived types. Additional sub-issues, for which the
    correspondence between Fortran and Ada (if any) ought to be
    illustrated, include
    .. Fortran allows for type extension;
    .. Fortran allows to parameterize derived types, with parameter
-      values specified for objects of the type.  "Kind" parameters
+      values specified for objects of the type. "Kind" parameters
       are required to have constant values, while "length" parameters
       can be specified by evaluation of expressions during execution;
    .. Fortran provides for type-bound procedures.
@@ -310,13 +310,13 @@
    interoperate with Fortran procedure pointers should be illustrated.
 
 -- Fortran has a "module" system that roughly corresponds to the Ada
-   package system, without generic parameters.  The use of the
+   package system, without generic parameters. The use of the
    Convention aspect of a package spec to declare the availability of
    Fortran module entities (at least subprograms) to Ada programs should
    be illustrated.
 
 -- Fortran has data pointers that are "fat," that is, that include array
-   bounds and strides, not simply addresses, such as C pointers.  The
+   bounds and strides, not simply addresses, such as C pointers. The
    correspondence of Ada access types and Fortran pointers, if there is
    any, should be illustrated.
 

Questions? Ask the ACAA Technical Agent