From rah@SSESCO.com Sun Feb 11 21:25:37 1996 Received: from garbanzo.SSESCO.com (garbanzo.ssesco.com [192.55.187.34]) by dkuug.dk (8.6.12/8.6.12) with SMTP id VAA16596 for ; Sun, 11 Feb 1996 21:25:31 +0100 From: rah@SSESCO.com Received: from chips.ssesco.com by garbanzo.SSESCO.com (AIX 3.2/UCB 5.64/4.03.SSESCO.srv.92.07.22) id AA18404; Sun, 11 Feb 1996 14:22:36 -0600 Received: by chips.SSESCO.com (AIX 3.2/UCB 5.64/4.03.SSESCO.cli.92.10.15) id AA23798; Sun, 11 Feb 1996 14:22:35 -0600 Message-Id: <9602112022.AA23798@chips.SSESCO.com> Subject: X3J3 Liaison report on allocatable components To: sc22wg5@dkuug.dk (wg5) Date: Sun, 11 Feb 1996 14:22:34 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2037 X3J3/96-45R1 Page 1 of 1 To: WG5, X3J3, Malcolm Cohen From: /Parallel Subject: Liaison report on Allocatable Components TR References: Allocatable Components TR, Jan 28, 1996 Version (X3J3.1996-40) Allocatable Components TR- Additional Semantics (X3J3.1996-35) Date: February 9, 1996 X3J3 concurs with the Allocatable Components TR at this time, and has a few minor concerns. Due to the paper's late arrival not all committee members had a chance to review it. X3J3 briefly discussed the proposed additional semantics for assignment. The straw vote on whether the new semantics should be pursued was 8-2- 6. The straw vote on whether the "=>" operator should be overloaded for the new semantics was 1-11-4. There was considerable concern that this seems like a large addition at this stage of the TR process and is beyond the scope of the original TR. If anything further is proposed we would like to see more examples and and more rationale in time for the May X3J3 meeting. Comments on the TR. 1) The title and section 1.1 should be changed to reflect the fact that this TR now only applies to allocatable components, not parameterized data types. 2) Could you explain the utility of allocatable intent (in) dummies? Since they appear to have little use wouldn't it be better to prohibit them? 3) "FORMAT = UNFORMATTED" in the OPEN statement in the example in 3.2 should be changed to "FORM = 'UNFORMATTED' " 4) Section 3.4 about ultimate allocatable components is unclear. While we believe it is correct we feel more explanation is needed. We believe that the TRs will be almost a stand-alone document and that this description should be expanded. 5) X3J3 notes the change to section 9.4.2 and is pursuing enhancements to derived type I/O which could eliminate this restriction in F2000. 6) In the additional semantics, NOTE 7.46.2 is a line like A = (/ 1., 2., 3., /) missing?