From barnes@alsys.co.uk Tue Aug 23 13:16:06 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA22678; Tue, 23 Aug 94 13:16:06 EDT Received: from by inmet.camb.inmet.com (4.1/SMI-4.1) id AB04260; Tue, 23 Aug 94 13:15:52 EDT Received: from alsys.co.uk by eros.britain.eu.net with UUCP id ; Tue, 23 Aug 1994 18:14:18 +0100 Received: by alsys.alsys.co.uk (4.1/SMI-4.1.1) id AA17458; Tue, 23 Aug 94 17:25:12 BST Date: Tue, 23 Aug 94 17:25:12 BST From: barnes@alsys.co.uk (John Barnes) Message-Id: <9408231625.AA17458@alsys.alsys.co.uk> To: ada9x-mrt@inmet.com Subject: positional aggregates !topic Array aggregates !reference RM9X-4.3.3;5.0 !from John Barnes 94-08-23 <> !discussion It doesn't seem to say anywhere that for an array aggregate in positional notation that the components are given in index order, nor that in the case of a positional aggregate with others those components represented by others follow on from those given explicitly. In Ada 83 this stuff was in the general aggregate section 4.3. The intent seems to have been to move it into the record and array sections as appropriate. That for records is there in 4.3.1(10). In the case of arrays it seems to have vanished. From HAC2GM!IOSSVR::IOSSVR::MRGATE:: Tue Aug 23 14:36:45 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA01127; Tue, 23 Aug 94 14:36:45 EDT Received: from igate1.hac.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA08347; Tue, 23 Aug 94 14:36:42 EDT Received: by igate1.hac.com (4.1/SMI-4.1) id AA16386; Tue, 23 Aug 94 11:35:14 PDT Date: Tue, 23 Aug 94 11:35:14 PDT Message-Id: <9408231835.AA16386@igate1.hac.com> Received: by DniMail (v1.0); Tue Aug 23 11:35:12 1994 PDT From: "HAC2GM!IOSSVR::IOSSVR::MRGATE::(IOSSVR::A1::VCELI)"@igate1.hac.com(IOSSVR::A1::VCELI)(IOSSVR::A1::VCELI)(IOSSVR::A1::VCELI) To: HAC2GM::IGATE1::"ada9x-mrt@inmet.com"@igate1.hac.com Subject: Loop in exit statement and target of goto statement From: NAME: Vincent Celier FUNC: Product Development TEL: To: "ada9x-mrt@inmet.com"@INTERNET !topic The loop in an exit_statement !reference RM9X-5.7(1);5.0 !from Vincent Celier 94-08-23 <> !discussion Paragraph 5.7(1) says: "An exit_statement is used to complete the execution of an enclosing loop_statement (called the loop in what follows); ..." The phrase between parentheses was in RM83. However, in the normative part of clause 5.7, the term "loop" alone is never used. It is only used in informative NOTE and examples. So, I think that "(called the loop in what follows)" should be deleted. !topic but does not enclose the target {statement}. !reference RM9X-5.8(5);5.0 !from Vincent Celier 94-08-23 <> !discussion From HAC2GM!IOSSVR::IOSSVR::MRGATE:: Tue Aug 23 14:36:55 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA01196; Tue, 23 Aug 94 14:36:55 EDT Received: from igate1.hac.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA08350; Tue, 23 Aug 94 14:36:51 EDT Received: by igate1.hac.com (4.1/SMI-4.1) id AA16412; Tue, 23 Aug 94 11:35:36 PDT Date: Tue, 23 Aug 94 11:35:36 PDT Message-Id: <9408231835.AA16412@igate1.hac.com> Received: by DniMail (v1.0); Tue Aug 23 11:35:33 1994 PDT From: "HAC2GM!IOSSVR::IOSSVR::MRGATE::(IOSSVR::A1::VCELI)"@igate1.hac.com(IOSSVR::A1::VCELI)(IOSSVR::A1::VCELI)(IOSSVR::A1::VCELI) To: HAC2GM::IGATE1::"ada9x-mrt@inmet.com"@igate1.hac.com Subject: Predefined library units and parameter modes From: NAME: Vincent Celier FUNC: Product Development TEL: To: "ada9x-mrt@inmet.com"@INTERNET !topic Modes of parameters in predefined library units !reference RM9X-A(2);5.0 !from Vincent Celier 94-08-23 <> !discussion In RM83, The general rule for the modes of parameters in subprograms in predefined library units is: - default mode for functions (no reserved word in) - explicit mode for procedure (if mode in, the reserved word in is present) There are exceptions: - in all input-output library units with functions, the reserved word in is present (TEXT_IO, DIRECT_IO, SEQUENTIAL_IO) - In DIRECT_IO, there is no mode indicated for parameter POSITIVE_COUNT in procedures READ and WRITE - A similar inconsistency exists in package LOW_LEVEL_IO. In Ada9X, package Low_Level_IO does not exist, and the inconsistency in Direct_IO has been corrected. For procedures, in Ada9X, modes are always indicated. However, for functions, there are three styles: - The general style: no explicit mode (no reserved word in) - Explicit mode (reserved word is present) for parameters of functions including operators if there are any. This style is adopted in the following predefined library units: - Ada.Characters.Handling - Ada.Command_Line - Ada.Direct_IO - Ada.Sequential_IO - Ada.Streams.Stream_IO - Ada.Strings.Bounded (contains operators) - Ada.Strings.Fixed (contains operators) - Ada.Strings.Unbounded (contains operators) - Ada.Text_IO - Ada.Text_IO.Editing - Interfaces - Interfaces.C - Interfaces.C.Pointers - Interfaces.C.Strings - Interfaces.COBOL - Interface.Fortran - Explicit mode for normal functions, but no explicit mode for operators. This style is adopted in the following predefined library units: - Ada.Strings - Ada.Strings.Maps Furthermore, in the last 4 "&" operators declared in package Ada.Strings.Unbounded, explicit mode in is indicated for the first parameter, while it is not for the second parameter. This last inconsistency should be corrected. We should decided if explicit mode should be indicated for operators when it is indicated for functions in the same package specification. !topic References of predefined library units !reference RM9X-A(2);5.0 !from Vincent Celier 94-08-23 <> !discussion There are some minor errors in the references for predefined library units that are listed in paragraph A(2). - Ada.Exceptions appears in subclause 11.4.1 and no longer in 11.2 - Ada.Exceptions.Messages does not exist any longer and should be deleted from this list - Ada.Wide_Text_IO is mentioned in clause A.11, but not in subclause A.10.1 - the specification of Interfaces is precisely in clause B.2