!standard  1(1)                                   12-11-26  AI05-0299-1/01
!standard  1(2/3)
!standard  1.1(1)
!standard  1.2(1)
!standard  1.2(1.1/3)
!standard  1.2(4.1/3)
!standard  1.2(6)
!standard  1.3(0)
!standard  3.5.1(5/3)
!standard  4.1.5(10/3)
!standard  4.1.5(11/3)
!standard  6.4(20)
!standard  6.4(23)
!standard  6.5(2.2/3)
!standard  8.6(27.1/3)
!standard  13.4(11/1)
!standard  A.32.18(10/3)
!standard  A.32.18(14/3)
!standard  A.32.18(17/3)
!class presentation 12-11-16
!status Amendment 2012 11-11-16
!status work item 12-11-16
!status received 12-11-16
!priority Low
!difficulty Easy
!qualifier Omission
!subject Last-second presentation issues in the Standard

!summary

This AI corrects minor errors in the Standard and addresses comments from
ITTF.

1) Remove unneeded ']' at the end of 3.5.1(5/3) and unneeded '}' at the end
of 13.4(11/1).

2) Replace the missing keyword return in 6.5(2.2/3).

3) Add a hyphen in "stand-alone" in 8.6(27.1/3).

4) Make the corrections to A.18.32 listed in the !wording section.

5) Make the corrections to 4.1.5 listed in the !wording section.

6) Add discriminant values to type Person in 6.4(20) and 6.4(23).

7) Correct Foreword as indicated.

[Editor's note: There are also corrections to AARM 5.2(28.e/2),
6.1.1(27.j/3), and 6.5(21.p/3) which are not
detailed here, but details can be found in the !appendix.]

8) Update the Scope clause, and remove the text in the General clause.

9) Replace the initial paragraph of 1.2, and update the names of standards as
indicated.

10) Change title of 1.3 to "Terms and definitions".

11) Make changes as needed to eliminate formal use of "section".

!question

1) There is an extra ']' at the end of 3.5.1(5/3) and an extra '}' at the end
of 13.4(11/1). Should they be reemoved? (Yes.)

2) The keyword "return" appears to be missing from the syntax rule 6.5(2.2/3).
Fix this? (Yes.)

3) The Standard uses "stand-alone" consistently (more than 30 uses), except
in 8.6(27.1/3). Should this one use be changed? (Yes.)

4) The example in A.18.32 does not work. Should it be fixed? (Yes.)

5) The example 4.1.5(10-2/3) is rejected by my compiler. Is it wrong? (Yes.)

6) Type Person is defined in 3.10.1 with a non-defaulted discriminant. However,
it is used in 6.4(20) and 6.4(23) without discriminant values. Should this
be changed? (Yes.)

7) [From ITTF. Note: ITTF is the ISO group that actually publishes standards;
these comments have to be answered.] In the Foreword, use the standard
formulation for revision information. Information regarding annexes is no longer
given in the Foreword of International Standards.

8) [From ITTF.] 1.1 Scope should be the first clause of the technical content
(page 1). It shall describe the content of the document and be usable as an
abstract for marketing purposes.

9) [From ITTF.] In 1.2, uUse the current standard introductory paragraph.
Ensure that titles and year of publication of normative references are aligned
with the ISO online catalogue: http://www.iso.org/iso/home/store.htm

10) [From ITTF.] 1.3 has an incorrect title.

11) [From ITTF.] "General": The clause is the highest-level division of an
International Standard, "section" is obsolete.

!recommendation

(See summary.)

!wording

1) Remove ']' from 3.5.1(5/3) and '}' from 13.4(11/1).

2) Add the keyword return to the syntax rule 6.5(2.2/3).

3) Add a hyphen in "stand{-}alone" in 8.6(27.1/3).

4)
In A.18.32(17/3) replace:
    Nearest_Distance :=
                 Distance'Min (So_Far(E.To) + So_Far(Next),
                               So_Far(E.To));
by:
    Nearest_Distance := E.Length + So_Far(Next);

In A.18.32(10/3) delete:
    Reached(Source) := True;

In A.18.32(14/3) replace:
    if Next = Source then  -- No next node found, graph is not connected
with
    if Nearest_Distance = Distance'Last then
        -- No next node found, graph is not connected

5) Move 4.1.5(10/3) after 4.1.5(12/3).

Replace the second line of 4.1.5(11/3) with "limited private".

6) Modify 6.4(20):
   procedure Pair(Left, Right : in Person_Name := new Person{(M)});

Modify 6.4(23):
   Pair(Left => new Person{(F)}, Right => new Person{(M)});

7) Modify Foreword(4/3):

This third edition cancels and replaces the second edition (ISO/IEC 8652:1995),
{which has been technically revised}[of which it constitutes a technical
revision]. {It also}[This edition] incorporates the [contents of] Technical
Corrigendum [1 (]ISO/IEC 8652:1995:Cor.1:2001[)] and the Amendment [1 (]ISO/IEC
8652:1995:Amd.1:2007[)].

Delete Foreword(5).

8) Delete 1(1) and 1(2/3). Modify 1.1(1):

This International Standard specifies the form and meaning of programs written
in Ada. Its purpose is to promote the portability of Ada programs to a variety
of [data processing]{computing} systems.

{Ada is a programming language designed to support the construction of
long-lived, highly reliable software systems. The language includes facilities
to define packages of related types, objects, and operations. The packages may
be parameterized and the types may be extended to support the construction of
libraries of reusable, adaptable software components. The operations may be
implemented as subprograms using conventional sequential control structures, or
as entries that include synchronization of concurrent threads of control as part
of their invocation. Ada supports object-oriented programming by providing
classes and interfaces, inheritance, polymorphism of variables and methods, and
generic units. The language treats modularity in the physical sense as well,
with a facility to support separate compilation.}

{The language provides rich support for real-time, concurrent programming, and
includes facilities for multicore and multiprocessor programming. Errors can be
signaled as exceptions and handled explicitly. The language also covers systems
programming; this requires precise control over the representation of data and
access to system-dependent properties. Finally, a predefined environment of
standard packages is provided, including facilities for, among others,
input-output, string manipulation, numeric elementary functions, and random
number generation, and definition and use of containers.}

9) Replace 1.2(1) with:

The following documents, in whole or in part, are normatively referenced in this
document and are indispensable for its application. For dated references, only
the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.

In 1.2(1.1/3), replace "ISO/IEC" with "ISO" and delete the first title element
"Terminology and other language and content resources -".

In 1.2(4.1/3), delete the first title element "Information and documentation -".

Modify 1.2(6):

ISO/IEC 8859-1:{1998}[1987], Information {technology}[processing] - 8-bit
single-byte coded {graphic} character sets - Part 1: Latin alphabet No. 1.

10) Replace the title of 1.3 with "Terms and definitions".

11) All section ("clause", according to ITTF) headers should be revised from
"Section N: <title>" to "N   <title>". (That's three hard spaces.)
Replace "section" with "clause" in the body text, capitalized when referring to
a specific clause number. Replace "clause" with "subclause" when referring to
second-level headings.

The titles and cross-references were changed via the tools; other changes
were made in the following paragraphs (these changes are to replace "clause"
by "subclause" and "section" by "clause", additional changes are noted):

Introduction (57.1-57.21)
Introduction (61)
Introduction (77.2/2)
1.1.2(1) Also "fourteen" is replaced by
	 "fifteen" (this latter change was missed in Ada 2005 as well).
AARM 1.1.2(1.a) Added note to explain that neither you nor us are losing
our minds -- it's ISO.
1.1.2(3)
1.1.2(24) Also removed "and subclause".
AARM 1.1.2(26.a)
1.1.4(14.2/3)
2(1)
2.1(4.1/3)
2.1(5/3)
AARM 2.1(19.c/2)
AARM 2.1(19.f/2)
AARM 2.2(14.c/2)
2.3(5/3)
AARM 2.5(5.a)
AARM 2.9(3.b)
3(1)
AARM 3.1(12.f)
AARM 3.1(12.g)
AARM 3.1(12.l)
AARM 3.1(12.n)
AARM 3.2(4.b/2)
AARM 3.2(13.a)
AARM 3.2(13.g/2)
AARM 3.3(26.c)
3.2.4(1/3)
3.3.1(6/3)
AARM 3.3.2(1.a)
3.3.2(4)
AARM 3.4(35.a/2)
AARM 3.5(5.b/3)
3.5.2(9)
3.5.5(10)
AARM 3.7(37.j/2)
AARM 3.7.1(1.a) - also properly linked the section reference.
3.7.1(14)
AARM 3.8.1(29.c)
AARM 3.9.4(17.a/2)
AARM 3.10(1.b)
3.10.2(1)
AARM 3.11.1(6.a)
4(1)
AARM 4.1(17.j/3)
AARM 4.4(11.a)
4.6(1)
4.6(4)
AARM 4.6(71.i)
AARM 4.8(5.g/3)
AARM 4.9(44.n)
5(2/2)
AARM 5.1(12.g)
5.2(14)
AARM 5.5(21.b/3)
6(2) "Section 9" is replaced by "9.5.2" (a proper reference to where entries are defined).
6.1(10/2)
AARM 6.1(42.b) "Section 10" is replaced by "10.1.1" (a proper reference to where
     parent_unit_name is defined).
AARM 6.4.1(18.b) - delete "clauses and".
AARM 6.5(28.c)
AARM 6.6(2.a)
AARM 7.1(17.b)
7.2(5)
AARM 7.3.2(14.b/3) - Should always have been "subclause".
AARM 7.4(14.h)
AARM 7.5(23.b)
AARM 7.5(23.f/3)
7.6.1(21)
AARM 7.6.1(24.v)
8(1)
8(2)
AARM 8.2(3.a)
AARM 8.2(12.a/2)
AARM 8.2(12.d)
AARM 8.5.4(1.a)
8.6(1)
AARM 8.6(34.e)
9(1)
AARM 9.1(9.a)
AARM 9.2(11.b)
AARM 9.4(11.a)
AARM 9.4(35.a)
AARM 9.5.2(22.a)
9.7.1(20)
AARM 9.7.2(7.a)
AARM 9.7.3(6.a)
AARM 9.8(24.a)
10(1)
10(3)
AARM 10(3.f)
AARM 10.1.2(6.a)
AARM 10.1.4(8.a)
10.2(28)
AARM 10.2.1(18.a/3)
11(1)
AARM 11.2(5.b)
AARM 11.4(7.b)
AARM 11.4.3(11.a) -- note that this note is on the wrong subclause (this is
     an example), but I don't know where it really belongs.
11.6(1)
11.6(2)
11.6(3)
AARM 11.6(2.e)
AARM 11.6(6.d)
AARM 11.6(6.f)
AARM 11.6(6.h)
11.6(7)
AARM 11.6(7.g)
AARM 12.1(24.c)
AARM 12.3(1.a)
AARM 12.3(11.aa)
AARM 12.5(16.i/3)
AARM 12.6(5.a)
AARM 12.6(7.a)
13(1/1)
AARM 13(1.a)
AARM 13.1(19.a) Replaced "Section 2" with "2.8", since this is talking about rules for pragmas (only).
13.9(17)
13.14(1)
13.14(2.1/3)
AARM 13.14(18.a/2)
A.1(1)
AARM A.2(4.e)
A.3(1/3)
AARM A.3(1.a)
A.3.5(55/3)
A.3.5(59/3)
A.4(1/2)
AARM A.4(1.a)
A.4.10(3/3)
A.7(2)
A.7(14)
A.10(1)
A.10(2)
AARM A.13(14.a/3)
AARM A.15(22.b)
AARM A.16(1.a/2)
A.18(5.a/2)
A.18(5.w/2)
A.18.4(2/2) "section" was never right here; this should have been "clause" in
   Ada 2005, and now is "subclause".
A.18.7(2/2) Same as A.18.4(2/2).
B(2/3)
B.2(13)
B.3(2/3)
C.1(1)
C.2(1/2)
C.3(1)
C.4(1)
C.6(1/3)
C.7(1/2)
AARM C.7(1.a/2)
D.1(1)
D.2(1/2)
AARM D.2(1.a/2)
D.2.1(11)
D.2.2(0.1/2)
D.2.3(1/2)
D.2.4(1/2)
D.2.5(1/2)
D.2.6(2/3)
D.3(1)
D.4(1/1)
D.5(1/2)
D.5(1.a/2)
D.5.1(1)
D.5.1(19.c/2) - Rewrote to avoid confusion ("subclause" now refers to any
subdivision whose number includes a dot).
D.5.2(1/2)
D.6(1)
D.7(1)
D.8(1)
D.9(1)
D.10(1)
D.11(1)
D.12(1)
D.13(1/3)
D.14(1/2)
D.14.1(1/2)
D.14.2(1/2)
D.14.3(1/3)
D.15(1/2)
D.16(1/3)
D.16.1(1/3)
AARM E.2(4.a/2)
E.2(5/3) - "this clause and its subclauses" is replaced by
   "this and the following subclauses".
AARM E.2(14.c/3)
E.3(1)
E.5(27.1/2)
AARM E.5(27.d/2)
F.3.1(1) - note: this always should have been "subclause".
AARM G.3(1.c/2)
H.4(1)
AARM H.4(28.e/2)
H.6(1/2)
AARM J.10(8.a/2)
AARM J.11(2.b/2)
AARM J.12(1.b/2)
AARM J.13(5.a/2)
AARM J.14(6.a/2)
AARM J.15(1.a/3)
AARM J.15.1(6.d/3) - Should always have been "subclause".
AARM J.15.2(4.a/3) - Should always have been "subclause".
AARM J.15.3(4.a/3) - Should always have been "subclause".
AARM J.15.4(5.a/3) - Should always have been "subclause".
AARM J.15.5(15.a/3) - Should always have been "subclause".
AARM J.15.6(4.a/3) - Should always have been "subclause".
AARM J.15.7(8.b/3) - Should always have been "subclause".
AARM J.15.8(10.a/3) - Should always have been "subclause".
AARM J.15.11(12.a/3) - Should always have been "subclause".
AARM J.15.12(5.a/3) - Should always have been "subclause".
AARM J.15.13(4.a/3) - Should always have been "subclause".
K.1(1/3)
K.2(1/3)
M(1/2)
P(1/2)
Q.1(1/2)
Q.2(1/2)
Q.3(1/2)
Q.4(1/2)
Q.5(1/2)


!discussion

1) These are just typos. Note that the stray character in 13.4(11/1) was
present in the printed consolidated Ada 2005 book.

2) This is normative text, however, the missing keyword is clearly an editing
error as the associated AI (AI05-0277-1) has the keyword in the proposed
wording change. As such, we've treated it as a presentation error.

3) This is just a typo.

4) This is an example, so it is not normative. Examples that don't work
increase confusion, so we fix this immediately.

5) The example is not legal because Find is primitive for two tagged types,
and because the object freezes the type before the primitive operation is
declared. This is an example, so it is not normative, and we correct it
because example that contain errors aren't helpful.

6) This is an example, so it is not normative. Examples with silly errors
are not helpful, so we fix this immediately.

7) ITTF asks for minor changes in the boilerplate for the Foreword. ITTF gets
what ITTF wants.

8) ITTF asks to move the text preceeding the scope into the Scope section. The
wording is slightly improved for marketing purposes (to include object-oriented
programming, multicore, and multiprocessing).

9) ITTF asks to change the boilerplate introduction to 1.2, and correct some
naming errors. They also asked use to consider whether we should be referencing
newer versions of 1539-1 (Fortran) and 8859-1 (Latin-1). For Fortran, we
decided to make no change as we have not yet considered what if any changes will
be needed to B.4 to support Fortran 2010. Thus the older reference is more
accurate. For Latin-1, the changes to the standard mostly were to align it with
10646, and are not relevant to its use in the Ada Standard. Thus we changed to
use the current document.

10) ITTF wants a different title, so it shall be.

11) This is the second time that we've had to change the names of the
subdivisions (Ada 83 used "chapter" and "section"; Ada 95 and 2005 used
"section" and "clause"). This is madness, but we have no choice.

!ACATS test

None needed.

!appendix

From: Maxim Reznik
Sent: Tuesday, October 9, 2012  2:23 PM

!topic extended_return_statement ::= {return} extended_return_object_declaration
!reference Ada 2012 RM-6.5(2.2/3)
!from Maxim Reznik 12-10-09
!keywords missing return keyword
!discussion

It seems return keyword accidentally disappeared from syntax rule.

[Editor's note: I also received private reports of this mistake from
Christoph Grein and Adam Beneschan. Thanks to all.]

****************************************************************

From: Tucker Taft
Sent: Wednesday, October 10, 2012  7:41 AM

Good point!

****************************************************************

From: Pascal Pignard
Sent: Friday, October 26, 2012  12:17 PM

!topic GNAT compilation error
!reference 4.1.5_9 and 4.1.6_18
!from Pascal Pignard 12-10-26
!discussion

AARM extract:
9/3     {AI05-0268-1}
        type Barrel is tagged ...  -- holds objects of type Element
10/3    {AI05-0268-1} B: aliased Barrel;
11/3    {AI05-0139-2} type Ref_Element(Data : access Element) is
           new Ada.Finalization.Limited_Controlled with private
              with Implicit_Dereference => Data;
                -- This Ref_Element type is a "reference" type.
                -- "Data" is its reference discriminant.
12/3    {AI05-0139-2} {AI05-0268-1}
        function Find (B : aliased in out Barrel; Key : String) return Ref_Element;
           -- Return a reference to an element of a barrel.

GNAT complains that Find is declared too late after B declaration.

See full compile example:
   package Parapraph_4_1_5_9 is
      type Element is new Integer;
      type Barrel is tagged record  -- holds objects of type Element
         E : Element;
      end record;
      B: aliased Barrel;  -- -> GNAT report: no primitive operations for "Barrel" after this line
      type Ref_Element(Data : access Element) is
        new Ada.Finalization.Limited_Controlled with private
      with Implicit_Dereference => Data;
      -- This Ref_Element type is a "reference" type.
      -- "Data" is its reference discriminant.
      function Find (B : aliased in out Barrel; Key : String) return Ref_Element; -- -> GNAT report: this primitive operation is declared too late
      -- Return a reference to an element of a barrel.
   private
      type Ref_Element(Data : access Element) is
        new Ada.Finalization.Limited_Controlled with null record
      with Implicit_Dereference => Data;
   end;
   package body Parapraph_4_1_5_9 is
   begin
      Find (B, "grape") := Element'(0);  -- Assign through a reference.
      Find (B, "grape").Data.all := Element'(1);
   end;

When I move B declaration after Find then GNAT complains again about Find:
operation can be dispatching in only one type

Shouldn't Barrel type be simple record type?
(not tagged)

Same in 4.1.6_18 where Indexed_Barrel type must be tagged and Find can be
dispatching in only one type.

****************************************************************

From: Adam Beneschan
Sent: Friday, November 2, 2012  4:41 PM

> Shouldn't Barrel type be simple record type?
> (not tagged)

That won't do; surely we want users to be able to used generalized references on
tagged types!  So providing an example that works on an untagged type, but gets
errors if the user tried to use it with a tagged type, isn't a good idea.

If anything, Ref_Element should be untagged.  That's the way it is in
Ada.Containers.Vectors (the Vector type is tagged, but Constant_Reference_Type
and Reference_Type are untagged, at least in the partial view).  It can have a
tagged component of type Ada.Finalization.Limited_Controlled, if necessary.  "B"
should just be moved down.

****************************************************************

From: Pascal Pignard
Sent: Monday, November 5, 2012  1:41 PM

Well ok Barrel is expected to be tagged then an error remains on Find:
operation can be dispatching in only one type

Is it a wrong issue of GNAT?

****************************************************************

From: Randy Brukardt
Sent: Monday, November 5, 2012  7:17 PM

No, you missed Adam's point: Barrel is expected to be tagged, but
*Ref_Element* is NOT expected to be tagged. Ref_Element shouldn't be derived
from Limited_Controlled, it simply should be private (or limited private):

   type Ref_Element(Data : access Element) is limited private
       with Implicit_Dereference => Data;
           -- This Ref_Element type is a "reference" type.
           -- "Data" is its reference discriminant.

Nothing in the example requires Ref_Element to be (visibly) controlled. As Adam
noted, this is how the containers work.

Once Ref_Element is not tagged, the error on Find will go away.

****************************************************************

From: Pascal Pignard
Sent: Thursday, November 8, 2012  2:15 PM

Well Randy, you're right, I didn't catch Adam point on Ref_Element.

So, is the following code proposal more suitable to illustrate the example:

   package Parapraph_4_1_5_9 is
      type Element is new Integer;
      type Barrel is tagged record  -- holds objects of type Element
         E : aliased Element;
      end record;

      type Ref_Element(Data : access Element) is limited private -- CHANGE
      with Implicit_Dereference => Data;
      -- This Ref_Element type is a "reference" type.
      -- "Data" is its reference discriminant.

      function Find (B : aliased in out Barrel; Key : String) return Ref_Element;
      -- Return a reference to an element of a barrel.
        B: aliased Barrel; -- CHANGE
   private
      type Ref_Element(Data : access Element) is null record -- CHANGE
      with Implicit_Dereference => Data;
   end;

   package body Parapraph_4_1_5_9 is
      function Find (B : aliased in out Barrel; Key : String) return Ref_Element is
      begin return R : Ref_Element(B.E'access); end;
   begin
      Find (B, "grape") := Element'(0);  -- Assign through a reference.
      Find (B, "grape").Data.all := Element'(1);
   end;

Result : no compilation issue, idem for example 4.1.6_18.

****************************************************************

From: Tucker Taft
Sent: Monday, November 5, 2012  8:48 AM

I happened to notice the "shortest-path" example in A.18.32, sort of for the
first time today. I decided to translate in into ParaSail just for fun.  Alas,
it didn't work! At first of course I suspected the ParaSail
compiler/interpreter, but after studying it a bit, it became clear that the Ada
algorithm is quite broken. Anyone remember the history of this?  I think I can
probably figure out how to fix it, but it might be faster for the original
author.

Actually, I have now studied it further, and have debugged it in the ParaSail,
and have ported the fixes back to the Ada (all attached).  GNAT doesn't yet like
the Ada, but it may be that my local copy of GNAT is a bit out of date
(cobbler's children and all that... ;-).  I'll try the newest GNAT on it, and
then report either to our Ada compiler folks or to the ARG depending on where is
the problem...

---

Attachment: shortest_path.adb

package body Shortest_Paths is
   function Shortest_Path
     (G : Graphs.Vector; Source : Node; Target : Node) return Paths.List
   is
      use Adjacency_Lists, Node_Maps, Paths, Graphs;
      Reached  : array (Node) of Boolean := (others => False);
      -- The set of nodes whose shortest distance to the source is known.

      Reached_From : array (Node) of Node;
      So_Far   : array (Node) of Distance := (others => Distance'Last);
      The_Path : Paths.List := Paths.Empty_List;
      Nearest_Distance : Distance;
      Next     : Node;
   begin
      So_Far(Source)  := 0.0;

      while not Reached(Target) loop
         Nearest_Distance := Distance'Last;

         -- Find closest node not reached yet, by iterating over all nodes.
         -- A more efficient algorithm uses a priority queue for this step.

         Next := Source;
         for N in Node'First .. Node'Last loop
            if not Reached(N)
              and then So_Far(N) < Nearest_Distance then
                 Next := N;
                 Nearest_Distance := So_Far(N);
            end if;
         end loop;

         if Nearest_Distance = Distance'Last then
            -- No next node found, graph is not connected
            return Paths.Empty_List;

         else
            Reached(Next) := True;
         end if;

         -- Update minimum distance to newly reachable nodes.

         for E of G (Next) loop
            if not Reached(E.To) then
               Nearest_Distance := E.Length + So_Far(Next);

               if Nearest_Distance < So_Far(E.To) then
                  Reached_From(E.To) := Next;
                  So_Far(E.To) := Nearest_Distance;
               end if;
            end if;
         end loop;
      end loop;

      -- Rebuild path from target to source.

      declare
         N : Node := Target;
      begin
         while N /= Source loop
            N := Reached_From(N);
            Prepend (The_Path, N);
         end loop;
      end;

      return The_Path;
   end;
end Shortest_Paths;

[Editor's note: The unchanged specification of Shortest_Paths and the
Parasail versions are omitted here.]

****************************************************************

From: Ed Schonberg
Sent: Monday, November 5, 2012  1:22 PM

> I happened to notice the "shortest-path" example in A.18.32, sort of
> for the first time today. I decided to translate in into ParaSail just for
> fun.  Alas, it didn't work! At first of course I suspected the ParaSail
> compiler/interpreter, but after studying it a bit, it became clear that
> the Ada algorithm is quite broken.
> Anyone remember the history of this?  I think I can probably figure
> out how to fix it, but it might be faster for the original author.

I wrote the original version, and incorporated a few ARG comments. it's a fairly
direct transcription of the standard algorithm.

> Actually, I have now studied it further, and have debugged it in the
> ParaSail, and have ported the fixes back to the Ada (all attached).
> GNAT doesn't yet like the Ada, but it may be that my local copy of
> GNAT is a bit out of date (cobbler's children and all that... ;-).
> I'll try the newest GNAT on it, and then report either to our Ada
> compiler folks or to the ARG depending on where is the problem...

Latest version of GNAT does not accept it either, so your Ada compiler folks are
on notice....

****************************************************************

From: Tucker Taft
Sent: Monday, November 5, 2012  1:42 PM

> ...
> I wrote the original version, and incorporated a few ARG comments. it's a
> fairly direct transcription of the standard algorithm.

Not quite direct enough, apparently... ;-)

****************************************************************

From: Randy Brukardt
Sent: Tuesday, November 20, 2012  7:21 PM

It would have been nice to have the changes marked somehow, as I had to do a
by-hand line-by-line compare to see what you changed.

I found essentially two things. First, the original version (original in that it
is in the Standard, I didn't go back and look at the *really* original version)
never used the Length component of the edge data. It should be pretty obvious
that there is no way that could work. So Tucker replaced So_Far(E.To) with the
edge distance from the edge data. (Otherwise, no edge distances would ever get
into So_Far, that couldn't work.)

The second change is to consider the Source point unreached, so that the first
iteration fills in the points reachable directly from the Source. The original
code assumed the Source was reached, but then how the first edges would get
involved is unclear.

---

To summarize the changes:

(1) In A.18.32(17/3) replace:
    Nearest_Distance :=
                 Distance'Min (So_Far(E.To) + So_Far(Next),
                               So_Far(E.To));
by:
    Nearest_Distance := E.Length + So_Far(Next);

(We don't need 'Min here because the next statement tests Nearest_Distance
against So_Far(E.To), so that's just redundant.)

(2A) In A.18.32(10/3) delete:
    Reached(Source) := True;

(2B) In A.18.32(14/3) replace:
    if Next = Source then  -- No next node found, graph is not connected
with
    if Nearest_Distance = Distance'Last then
        -- No next node found, graph is not connected

(Because the first iteration will have Next = Source, so we can't use that as a
marker.)

---

If anyone sees anything wrong with this, please tell us ASAP (this will be a
correction in the final Ada 2012 Standard, so I'd prefer to get it right).

P.S. AI05-0212-1 is where the Ed's originally proposed code is located. I looked
at versions /06 and /07 of the AI, and none seem to use the .Length component
anywhere. So I don't know how the original version worked. OTOH, I didn't find
the original version of the code before I and others started "improving" it;
perhaps it was sent privately. So I don't know if we improved it too much (most
likely).

****************************************************************

From: Tucker Taft
Sent: Tuesday, November 20, 2012  7:50 PM

> It would have been nice to have the changes marked somehow, as I had
> to do a by-hand line-by-line compare to see what you changed.

Sorry about that!

> I found essentially two things. First, the original version (original
> in that it is in the Standard, I didn't go back and look at the
> *really* original version) never used the Length component of the edge
> data. It should be pretty obvious that there is no way that could
> work. So Tucker replaced So_Far(E.To) with the edge distance from the
> edge data. (Otherwise, no edge distances would ever get into So_Far,
> that couldn't work.)
>
> The second change is to consider the Source point unreached, so that
> the first iteration fills in the points reachable directly from the
> Source. The original code assumed the Source was reached, but then how
> the first edges would get involved is unclear.

Right-O.

>
> ---
>
> To summarize the changes:
>
> (1) In A.18.32(17/3) replace:
>      Nearest_Distance :=
>                   Distance'Min (So_Far(E.To) + So_Far(Next),
>                                 So_Far(E.To));
> by:
>      Nearest_Distance := E.Length + So_Far(Next);
>
> (We don't need 'Min here because the next statement tests
> Nearest_Distance agains So_Far(E.To), so that's just redundant.)
>
> (2A) In A.18.32(10/3) delete:
>      Reached(Source) := True;
>
> (2B) In A.18.32(14/3) replace:
>      if Next = Source then  -- No next node found, graph is not
> connected with
>      if Nearest_Distance = Distance'Last then
>          -- No next node found, graph is not connected
>
> (Because the first iteration will have Next = Source, so we can't use
> that as a marker.)

Yup.

> ---
>
> If anyone sees anything wrong with this, please tell us ASAP (this
> will be a correction in the final Ada 2012 Standard, so I'd prefer to get it
> right).

The ParaSail version worked.  I never got the Ada version to work, because GNAT
couldn't compile it.  I believe Ed has since fixed GNAT to swallow it.

****************************************************************

From: Pascal Pignard
Sent: Saturday, November 10, 2012  12:37 PM

!topic minor typo
!reference 5.2 Assignment Statements
!from Pascal Pignard 12-11-10
!discussion

5.2:
28.e            type AccNonLim is access NonLim;
                function Foo (Arg : in Integer) return AccNonLim;
                type AccLim is access Lim;
                function Foo (Arg : in Integer) return AccLim;
                Foo(2).all := Foo(1).all;.
Ending extra period    ------------^


****************************************************************

From: Ed Schonberg
Sent: Tuesday, November 20, 2012  8:57 PM

Your fixes are all correct. I won't try to figure out why I did not see those
bugs myself, but certainly when I wrote the algorithm we had not implemented
iterators to the point where I could compile and test the code.  The current
GNAT release compiles this properly. Thanks to you both for cleaning this up!

****************************************************************

From: Pascal Pignard
Sent: Sunday, November 11, 2012  2:29 PM

!topic Typo in example
!reference 6.1.1 Preconditions and Postconditions !from Pascal Pignard 12-11-11 !discussion

27.i/3          Table : array (1..10) of Integer := ...
                procedure Bar (I : in out Natural)
                   with Post => I > 0 and then Tab(I)'Old = 1; -- Illegal
27.j/3      In this example, the compiler cannot know the value of I when the
            subprogram returns (since the subprogram execution can change it),
            and thus it does not know whether Tab(I)'Old will be needed then.
            Thus it has to always create an implicit constant and evaluate
            Tab(I) when Bar is called (because not having the value when it is ...

Maybe array name is Tab instead of Table as it is referenced also in the
explanation text?

****************************************************************

From: Randy Brukardt
Sent: Tuesday, November 20, 2012  12:02 AM

This was privately reported and fixed back in July. Private reports are
preferred for Ada 2012 bugs at this stage because we will fix another round of
typos when the final standard is created, and reports here make extra work (all
mail here being given either an AI or AC to track them). OTOH, given that I'm
going to start creating that final standard in the next few days, I'd rather get
no reports at all until January or so. (I hate it when I have to redo things
several times because people send in beyond-last-minute bugs that have to be
fixed - dealing with ITTF is enough aggravation, thank you.)

****************************************************************

From: Pascal Pignard
Sent: Saturday, November 17, 2012  8:58 AM

!topic Missing discriminant value
!reference 6.4 Subprogram Calls
!from Pascal Pignard 12-11-17
!discussion

Type Person defined in 3.10.1 needs a discriminant value in Pair declaration
and usage at example 6.4 section 23 :
      -- ...
      procedure Pair(Left, Right : in Person_Name := new Person);   --  see 3.10.1 -- line 251
      -- ...
   begin
      Pair; -- line 259
      Pair(Left => new Person, Right => new Person); -- line 260
   end;

GNAT log:
aarm_2012_draft_17_p06.adb:251:54: uninitialized unconstrained allocation not allowed
aarm_2012_draft_17_p06.adb:251:54: qualified expression or constraint with discriminant values required
aarm_2012_draft_17_p06.adb:259:07: uninitialized unconstrained allocation not allowed
aarm_2012_draft_17_p06.adb:259:07: qualified expression or constraint with discriminant values required
aarm_2012_draft_17_p06.adb:260:20: uninitialized unconstrained allocation not allowed
aarm_2012_draft_17_p06.adb:260:20: qualified expression or constraint with discriminant values required
aarm_2012_draft_17_p06.adb:260:41: uninitialized unconstrained allocation not allowed
aarm_2012_draft_17_p06.adb:260:41: qualified expression or constraint with discriminant values required

It is solved with modification line 251 and 260:
      procedure Pair(Left, Right : in Person_Name := new Person(M)) is null;   --  see 3.10.1 -- line 251
      Pair(Left => new Person(F), Right => new Person(M)); -- line 260

****************************************************************

From: Pascal Pignard
Sent: Sunday, November 18, 2012  4:39 AM

!topic Minor typo
!reference 6.5 Return Statements
!from Pascal Pignard 12-11-18
!discussion

21.p/3          function F return Undiscriminated is
                   Local : aliased Integer;
                begin
                   return X : Undiscriminated := (Fld => (Discrim => Local'Access)) do
                      Foo;
                   end return;
                   -- raises Program_Error after calling Foo.
                end} F;  -- <-- extra }

****************************************************************

From: Randy Brukardt
Sent: Tuesday, November 20, 2012  6:42 PM

For the normative references section, ITTF says (in part):

"For 1539-1, consider whether the latest edition (2010) can be given."

"For 8859-1, consider whether the latest edition (1998) can be given, with
apprpriate title change."

1539-1 is Fortran. Based on the comments on Ada-Comment about the suitability of
Interfaces.Fortran for recent versions of Fortran, I'd tend to say no, we
shouldn't reference the latest edition. But I'm no expert on Fortran.

8859-1 is Latin-1. One wonders what changed about that standard in 1998.
Does anyone know? It's hard to imagine that it would be incompatible in any way
that we care about, but there is a danger in changing the reference.

Thoughts??

****************************************************************

From: Randy Brukardt
Sent: Wednesday, November 21, 2012  6:58 PM

Since no one commented on this, let me answer my own question:

> For the normative references section, ITTF says (in part):
>
> "For 1539-1, consider whether the latest edition (2010) can be given."
>
> "For 8859-1, consider whether the latest edition (1998) can be given,
> with apprpriate title change."
>
> 1539-1 is Fortran. Based on the comments on Ada-Comment about the
> suitability of Interfaces.Fortran for recent versions of Fortran, I'd
> tend to say no, we shouldn't reference the latest edition. But I'm no
> expert on Fortran.

As I suggested above, I don't think we want to change this.

> 8859-1 is Latin-1. One wonders what changed about that standard in 1998.
> Does anyone know? It's hard to imagine that it would be incompatible
> in any way that we care about, but there is a danger in changing the
> reference.

I researched this, and managed to find a link to the pre-publication draft of
8859-1:1998 (http://www.open-std.org/JTC1/SC2/WG3/docs/n411.pdf). It includes an
annex B listing the changes to that Standard. I also determined that there are
only two references to 8859-1 remaining in the Standard, in sections A.1
(package Standard) and A.3.3 (package Latin_1). Nothing in either of those
places depends in any interesting way on the contents of 8859-1 (the names of
the characters in package Latin_1 probably were taken from 8859-1:1987, but they
stand on their own just fine and thus we can ignore any changes). If we want to
do anything at all it would be to add an AARM note to A.3.3 to say that the
names were derived from 8859-1:1987 and they may be slightly different than the
names in current standards 8859-1:1998 and 10646:2011, but that seems like
overkill.

So I will change the reference to the 1998 edition as suggested by ITTF.

Please register any objections/comments before Monday.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, November 20, 2012  6:37 PM

Most of the ITTF comments on the Ada 2012 are boilerplate issues that need no discussion here. There are a couple that I want to get a bit of guidance on.

One of the ITTF comments is:

"Scope"

"The scope shall be the first clause of the technical content (page 1). It shall
describe the content of the document and be usable as an abstract for marketing
purposes."

"Move the two paragraphs above the scope either into the scope or elsewhere in
the document so that the scope title appears directly below the clause 1 title
as follows:
1   General
1.1   Scope
Consider redrafting the scope in line with comment column." (This is the text
quoted above which I believe comes from the ISO drafting standard.)

The "easy" fix here is just to move the two paragraphs of 1 (General) into 1.1
after the existing first sentence. That would look something like:

1.1 Scope

This International Standard specifies the form and meaning of programs written
in Ada. Its purpose is to promote the portability of Ada programs to a variety
of data processing systems.

Ada is a programming language designed to support the construction of
long-lived, highly reliable software systems. The language includes facilities
to define packages of related types, objects, and operations. The packages may
be parameterized and the types may be extended to support the construction of
libraries of reusable, adaptable software components. The operations may be
implemented as subprograms using conventional sequential control structures, or
as entries that include synchronization of concurrent threads of control as part
of their invocation. The language treats modularity in the physical sense as
well, with a facility to support separate compilation.

The language includes a complete facility for the support of real-time,
concurrent programming. Errors can be signaled as exceptions and handled
explicitly. The language also covers systems programming; this requires precise
control over the representation of data and access to system-dependent
properties. Finally, a predefined environment of standard packages is provided,
including facilities for, among others, input-output, string manipulation,
numeric elementary functions, and random number generation, and definition and
use of containers.

---------

Obviously, this is pretty clunky. Probably the first paragraph and a second
paragraph need to be combined in some manner.

Anyone out there have a suggestion?

****************************************************************

From: Tullio Vardanega
Sent: Wednesday, November 21, 2012  7:04 AM

The rearrangement does not ready that clunky to me.
Perhaps you may split the original scope paragraph in two (one per sentence) and
insert the original top text in the middle. Something like:

1.1 Scope

This International Standard specifies the form and meaning of programs written
in Ada.

Ada is a programming language designed to support the construction of
long-lived, highly reliable software systems. The language includes facilities
to define packages of related types, objects, and operations. The packages may
be parameterized and the types may be extended to support the construction of
libraries of reusable, adaptable software components. The operations may be
implemented as subprograms using conventional sequential control structures, or
as entries that include synchronization of concurrent threads of control as part
of their invocation. The language treats modularity in the physical sense as
well, with a facility to support separate compilation.

The language includes a complete facility for the support of real-time,
concurrent programming. Errors can be signaled as exceptions and handled
explicitly. The language also covers systems programming; this requires precise
control over the representation of data and access to system-dependent
properties. Finally, a predefined environment of standard packages is provided,
including facilities for, among others, input-output, string manipulation,
numeric elementary functions, and random number generation, and definition and
use of containers.

The purpose of this International Standard is to promote the portability of Ada
programs to a variety of data processing systems.

****************************************************************

From: Dan Eilers
Sent: Wednesday, November 21, 2012  10:54 AM

> 1.1 Scope
>
> This International Standard specifies the form and meaning of programs
> written in Ada.
...
> The purpose of this International Standard is to promote the
> portability of Ada programs to a variety of data processing systems.

It might be better to combine these two one-sentence paragraphs.

It also might be better to clarify in the second sentence that the intended
portability is not just between different computer systems, but also between
different Ada implementations on the same computer system.

****************************************************************

From: Erhard Ploedereder
Sent: Wednesday, November 21, 2012  11:32 AM

I like the rewrite [the one in the original message - Editor]
and would not combine para 1+2. (If anything para 2+3 are
unnecessarily separated, but they have been that way all along. We should have
added object-orientation there at some time.)

****************************************************************

From: Randy Brukardt
Sent: Wednesday, November 21, 2012  5:44 PM

> It might be better to combine these two one-sentence paragraphs.

Erhard agrees with you, and so do I upon reflection. (Besides, that's the way they currently are, so a change has to be clearly better.)

> It also might be better to clarify in the second sentence that the
> intended portability is not just between different computer systems,
> but also between different Ada implementations on the same computer
> system.

Not to mention that "data processing systems" is rather archaic and argubly
doesn't cover the most important uses of the language (in safety-critical
embedded systems). Nor does it seem to cover new markets like smartphones. OTOH,
this is intended to be marketing-oriented, and as such, details aren't that
critical. And argubly, "data processing system" includes both the development
system and the target hardware, so one could make a case that it's already
covered.

Does anyone have a suggestion for some phrase to replace "data processing
systems"? I was thinking about suggesting "computer systems", but that might be
interpreted as being more limited in scope than "data processing systems".

Another option is something along the lines of:

"The purpose of this International Standard is to promote the portability of Ada
programs created with any Ada processor to a variety of target systems."

But perhaps that's too pedantic.

In any case, the deadline for getting this published in 2012 turns out to be
early next week, so we don't have long to discuss this. In the absence of a
widely-agreed update, I'll make the minimum change required. So please respond
if you can (this being a long holiday weekend in the US, I realize many will be
away from their computers - I will be soon).

****************************************************************

From: Tucker Taft
Sent: Wednesday, November 21, 2012  6:06 PM

> Does anyone have a suggestion for some phrase to replace "data
> processing systems"? I was thinking about suggesting "computer
> systems", but that might be interpreted as being more limited in scope
> than "data processing systems"...

How about "computing systems"?

****************************************************************

From: Randy Brukardt
Sent: Wednesday, November 21, 2012  5:56 PM

> I like the rewrite and would not combine para 1+2. (If anything para
> 2+3 are unnecessarily separated, but they have been that way all
> along.
> We should have added object-orientation there at some time.)

You're right, it would be good to get another buzzword into the abstract.
That part in question is:

"The language includes facilities to define packages of related types, objects,
and operations. The packages may be parameterized and the types may be extended
to support the construction of libraries of reusable, adaptable software
components."

Unfortunately, I don't see a great way to get o-o into this, other than to just
graft it on.

"The language includes facilities to define packages of related types, objects,
and operations. The packages may be parameterized and the types may be extended
to support the construction of libraries of reusable, adaptable software
components. The packages and type facilities support many development styles
including object-oriented programming."

I don't find this very satisfying. Are there any better suggestions out there,
or should we forget this idea?

P.S. Remember, I need a resolution on this on Monday, as noted in my previous
message.

****************************************************************

From: Tucker Taft
Sent: Wednesday, November 21, 2012  6:04 PM

How about simply:

   The packages may be parameterized and the types may be extended to
   support the construction of libraries of reusable, adaptable
   object-oriented software components.

It doesn't say that you can *only* create object-oriented software components,
but it says it supports the creation of reusable libraries, and those are quite
likely to be object-oriented to some degree.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, November 21, 2012  6:36 PM

Thanks Tuck, sounds good to me (as does your other suggestion). What do the rest
of you think?

****************************************************************

From: Edmond Schonberg
Sent: Wednesday, November 21, 2012  7:19 PM

That sounds balanced and non-controversial, I'd go with it.

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 21, 2012  6:52 PM

> It doesn't say that you can *only* create object-oriented software
> components, but it says it supports the creation of reusable
> libraries, and those are quite likely to be object-oriented to some
> degree.

Well that position is certainly controversial. Alexander Stepanov for example,
one of the primary creators of the STL for C++, considers the whole business of
object oriented components to be misguided :-)

So let's avoid expressing a point of view on this. Ada allows creating
components either through genericity (like the STL using templates) or using
OOP. Let's not express a preference.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, November 21, 2012  7:04 PM

Remember, we're discussing Tucker's suggested wording here. In context, it would
say:

  The language includes facilities to define packages of related types, objects, and operations. The packages may be parameterized and the types may be extended to support the construction of libraries of reusable, adaptable object-oriented software components.

Is this expressing a "preference"? I'm not sure I see that. If you think it is,
please suggest an improvement that still keeps this short (it's supposed to be
an abstract, after all, and the main goal of the change is to get the buzzword
"object-oriented" into it, not to make it a lot longer).

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 21, 2012  7:27 PM

Yes, it implies that reusable and adaptable components are necessarily
object-oriented, which is a controversial position. One I certainly disagree
with.

****************************************************************

From: Edmond Schonberg
Sent: Wednesday, November 21, 2012  7:32 PM

That battle was fought and lost, I'm afraid. For 99% of the programming
community, components are object-oriented things. We may know better (perhaps)
but in this opening paragraph for the general public this is a reasonable thing
to state.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, November 21, 2012  8:00 PM

Ten minutes after Ed wrote:

  That sounds balanced and non-controversial, I'd go with it.

Robert writes:

  Yes, it implies that reusable and adaptable components are
  necessarily object-oriented, which is a controversial
  position. One I certainly disagree with.

Someone must be wrong here. :-)

Anyway, I don't see how the statement that you can create "reusable, adaptable
object-oriented components" implies anything about what else you can (or should)
create. Indeed, you can use Ada packages to create inflexible object-oriented
components and reusable but not-object-oriented components and even inflexible
not-object-oriented components. And the statement that you can create one type
certainly doesn't imply that the others don't exist.

Obviously, we could separate the statement into two parts:

The packages may be parameterized to support the construction of libraries of
reusable, adaptable object-oriented software. In addition, the types may be
extended to support the construction of object-oriented software components.

But I think this is way too pedantic and wordy.

****************************************************************

From: Bob Duff
Sent: Wednesday, November 21, 2012  7:44 PM

> Thanks Tuck, sounds good to me (as does your other suggestion). What
> do the rest of you think?

The "rest of us" trust you do Do The Right Thing.

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 21, 2012  9:45 PM

> That battle was fought and lost, I'm afraid. For 99% of the
> programming community, components are object-oriented things. We may know better (perhaps) but in this opening paragraph for the general public this is a reasonable thing to state.

Well it is certainly not true in C++, the STL is not object oriented at all! :-)

****************************************************************

From: Jean-Pierre Rosen
Sent: Thursday, November 22, 2012  3:02 AM

...
> Someone must be wrong here. :-)

I'd suggest:

The packages may be parameterized and the types may be extended to support the
construction of libraries of reusable, adaptable software components using
various design paradigms, such as (or including?) object oriented development.

****************************************************************

From: Erhard Ploedereder
Sent: Wednesday, November 21, 2012  5:41 AM

My wording change, if any, would be....

Add at the end of the old 1.(1) para:
It supports object-oriented programming by providing classes, inheritance, polymorphism of variables and methods, and generics.

Actually, my original remark was targeted at 2020. I would not start more than
minimal rewrites as part of these final responses. The issue at hand is not
critical.

****************************************************************

From: Erhard Ploedereder
Sent: Wednesday, November 21, 2012  5:56 AM

> How about simply:
>
>    The packages may be parameterized and the types may be extended to
>    support the construction of libraries of reusable, adaptable
>    object-oriented software components.
>
> It doesn't say that you can *only* create object-oriented software
> components, but it says it supports the creation of reusable
> libraries, and those are quite likely to be object-oriented to some
> degree.

Well, seems to me that O-O is too important to only be stuck as an attribute to
components. Compare this to how the real-time aspects are called out for. Also,
I share the view that "reusable object-oriented components" is certainly not the
essence of O-O. (It is actually it's weak point IMHO.)

****************************************************************

From: Robert Dewar
Sent: Thursday, November 22, 2012  6:00 AM

Erhard, I totally agree, can you suggest alternative wording?

****************************************************************

From: Randy Brukardt
Sent: Monday, November 26, 2012 12:26 PM

> My wording change, if any, would be....
>
> Add at the end of the old 1.(1) para:
> It supports object-oriented programming by providing classes,
> inheritance, polymorphism of variables and methods, and generics.

You omitted interfaces, was that intentional?

> Actually, my original remark was targeted at 2020. I would not start
> more than minimal rewrites as part of these final responses. The issue
> at hand is not critical.

2020 is a *long* ways off, and by then, no one will care about "object-oriented
programming". The world will have moved on to newer things. Indeed, I think you
can make a case that it has already lost its value as a buzzword; it's probably
as important to get to get "multi-core" and/or "multi-processor" into the
real-time sentence somehow. (Maybe: "The language includes a complete facility
for the support of real-time, concurrent programming, including facilities for
multi-core and multi-processor programming".

So I think it is either do this now or forget about it permanently.

****************************************************************

From: Erhard Ploedereder
Sent: Monday, November 26, 2012  4:48 PM

> You omitted interfaces, was that intentional?

No. If you put it in, make it "classes and interfaces,..."

> So I think it is either do this now or forget about it permanently.

Fine by me, as long as it on par with modularity and real-time.

> ... including facilities for multi-core and multi-processor
> programming"

This would be mostly a lie, which  I would not want to see as the first things
that the manual says. (MC-support is pityful in Ada12.)

****************************************************************

From: Robert Dewar
Sent: Monday, November 26, 2012  5:00 PM

>> ... including facilities for multi-core and multi-processor
>> programming"

I would put this in (my prev vote agreeing with Erhard was about his earlier
points)

> This would be mostly a lie, which  I would not want to see as the
> first things that the manual says. (MC-support is pityful in Ada12.)

I disagree pretty strongly with this pessimistic viewpoint. Compared to other
competing languages I think Ada is way ahead! We had many customers with
multi-tasking programs that were very impressed that they could take advantage
of multi-core by doing essentially nothing!

****************************************************************

From: Randy Brukardt
Sent: Monday, November 26, 2012  5:36 PM

I strongly agree with Robert here. I know that there is a lot of research into
finding the "holy grail" of getting multicore use for "free" in a programming
language, but I am very dubious that said research will ever amount to anything.
I find it hard to imagine that the solution to performance problems is going to
be found by adding more overhead (either in hardware or software). Thus, I think
that the best way to structure programs will remain large-grained parallelism, a
model that Ada already supports well. Moreover, portability concerns (no
hardware has a very long life these days) suggest that coding for a specific
architecture is almost certainly a dead-end.

Certainly there is more that can be done (especially with tasking contracts and
static checking thereof), but Ada has most of what's needed already -- and has
the distinct advantage of having considered these multiprocessor issues from day
one (and thus has nearly 30 years of practice already).

****************************************************************

From: Randy Brukardt
Sent: Monday, November 26, 2012 12:39 PM

I would like to get some guidance as to how to proceed here. My preference is
for #1 and #A below, but I definitely want these changes to be
non-controversial. Keep in mind that ISO intends to use this text as an
"abstract" to describe the Standard (and by corollary, the language). So please
let me know your preferences ASAP (I'll need answers by close-of-business
today).

---

Straw Poll #1: ("object-oriented").

Choice #1) [Jean-Pierre's suggestion] "The packages may be parameterized and the
	   types may be extended to support the construction of libraries of
	   reusable, adaptable software components{ using various design
	   paradigms, including object oriented development}."

Choice #2) [Erhard's suggestion] "The packages may be parameterized and the
	   types may be extended to support the construction of libraries of
	   reusable, adaptable software components. {It supports object-oriented
	   programming by providing classes, inheritance, polymorphism of
	   variables and methods, and generics.}"

Choice #3) Some other words (please propose).

Choice #4) Don't bother changing this, "object-oriented" isn't important enough
	   to get into the language abstract.

---

Straw Poll #2: ("multi-core").

Choice #A) "The language includes a complete facility for the support of
	   real-time, concurrent programming{, including facilities for
	   multi-core and multi-processor programming}."

Choice #B) Some other words (please propose).

Choice #C) Don't bother changing this, "multi-core" isn't important enough to
	   get into the language abstract.

****************************************************************

From: Edmond Schonberg
Sent: Monday, November 26, 2012 12:47 PM

I prefer #2 and concur on #A.  multi-core should be mentioned.

****************************************************************

From: Steve Baird
Sent: Monday, November 26, 2012  1:11 PM

I agree with Ed.

> Choice #2) [Erhard's suggestion] "The packages may be parameterized
> and the types may be extended to support the construction of libraries
> of reusable, adaptable software components. {It supports
> object-oriented programming by providing classes, inheritance,
> polymorphism of variables and methods, and generics.}"

Should the first word of #2 be changed from "It" to "Ada"? As it stands, the
intermediate sentence about "The packages" (which we are not discussing
changing) puts some distance between the pronoun and its resolution. Maybe it
(by which I mean "It") is fine as proposed.

I'm going to hit the send button before I waste any more time dithering about
whether this point is even worth mentioning.

****************************************************************

From: Tucker Taft
Sent: Monday, November 26, 2012  1:14 PM

#1 or #2, and #A, but with no hyphens: multicore and multiprocessor.

If you do a search, you will find most people spell multicore without a hyphen
these days, and even more so for multiprocessor.

****************************************************************

From: Bob Duff
Sent: Monday, November 26, 2012  1:18 PM

I vote for:

> Choice #4) Don't bother changing this, "object-oriented" isn't
> important enough to get into the language abstract.

> Choice #C) Don't bother changing this, "multi-core" isn't important
> enough to get into the language abstract.

I don't think anybody is going to read this stuff, and it's waste of time
arguing about it.

****************************************************************

From: Tullio Vardanega
Sent: Monday, November 26, 2012  1:49 PM

#2, replacing "It supports object-oriented programming" with "Ada also supports object-oriented programming".

#A, avoiding the duplicate use of "includes/ing" as follows:
"The language provides rich support for real-time, concurrent programming, and includes ..."

With apologises to Bob, who does not like this;-)

****************************************************************

From: Gary Dismukes
Sent: Monday, November 26, 2012  1:51 PM

I prefer #2 and #A.

(And I agree with Tuck about spelling "multicore" and "multiprocessor"
without hyphens.)

****************************************************************

From: Joyce L Tokar
Sent: Monday, November 26, 2012  1:54 PM

I vote for #2 and #A

****************************************************************

From: Erhard Ploedereder
Sent: Monday, November 26, 2012  4:54 PM

> Straw Poll #1: ("object-oriented").

Not surprisingly, I vote for Choice #2) [Erhard's suggestion] -- with "It"
replaced by "The language" and maybe even as an extra paragraph.

followed closely by choice 4 (do nothing).

> Straw Poll #2: ("multi-core")

Choice C: do nothing.

(Strong oposition to "multi-core" in Choice #A).

****************************************************************

From: Robert Dewar
Sent: Monday, November 26, 2012  4:58 PM

I agree with Erhard's vote,

****************************************************************

From: Robert Dewar
Sent: Monday, November 26, 2012  5:01 PM

>> Straw Poll #1: ("object-oriented").
>
> Not surprisingly, I vote for Choice #2) [Erhard's suggestion] -- with
> "It" replaced by "The language" and maybe even as an extra paragraph.
>
> followed closely by choice 4 (do nothing).

Clarifying, it's the above I agree with

>> Straw Poll #2: ("multi-core")
>
> Choice C: do nothing.
>
> (Strong oposition to "multi-core" in Choice #A).

And I disagree with this.

****************************************************************

From: Robert Dewar
Sent: Monday, November 26, 2012  5:02 PM

Please remember that the scope statements are marketing statements, not even
sure technical folk should be allowed to discuss them :-) :-)

****************************************************************

From: Randy Brukardt
Sent: Monday, November 26, 2012  6:30 PM

Consider the straw poll closed, as I have made the revisions to the standard. I
made a few editorial changes to the text we considered so that it would read
better and used some of the suggestions made during the polling. So I present
the entire scope subclause below (no changes are marked; the whole should be
considered).

If you have any comments, please send them in the next couple of hours as I hope
to put this (the Standard) to bed tonight. (Apologies in advance to the
Europeans that are asleep.)

P.S. If I was going to change anything, I would simplify the unnecessarily wordy
"a facility to support separate compilation" and possibly emphasize that
checking is preserved, something like "supporting separate compilation while
continuing to enforce the rules of the language". Getting too late to do that,
however.

---

1.1 Scope

This International Standard specifies the form and meaning of programs written
in Ada. Its purpose is to promote the portability of Ada programs to a variety
of computing systems.

Ada is a programming language designed to support the construction of
long-lived, highly reliable software systems. The language includes facilities
to define packages of related types, objects, and operations. The packages may
be parameterized and the types may be extended to support the construction of
libraries of reusable, adaptable software components. The operations may be
implemented as subprograms using conventional sequential control structures, or
as entries that include synchronization of concurrent threads of control as part
of their invocation. Ada supports object-oriented programming by providing
classes and interfaces, inheritance, polymorphism of variables and methods, and
generic units. The language treats modularity in the physical sense as well,
with a facility to support separate compilation.

The language provides rich support for real-time, concurrent programming, and
includes facilities for multicore and multiprocessor programming. Errors can be
signaled as exceptions and handled explicitly. The language also covers systems
programming; this requires precise control over the representation of data and
access to system-dependent properties. Finally, a predefined environment of
standard packages is provided, including facilities for, among others,
input-output, string manipulation, numeric elementary functions, and random
number generation, and definition and use of containers.

****************************************************************

From: Robert Dewar
Sent: Monday, November 26, 2012  6:39 PM

This seems fine to me!

****************************************************************

From: Joyce L Tokar
Sent: Monday, November 26, 2012  9:43 PM

ship it!

****************************************************************

From: Erhard Ploedereder
Sent: Tuesday, November 27, 2012  9:27 AM

Go for it!

****************************************************************