From LJM@SLACVM.BITNET Tue Dec 13 11:02:00 1994 Received: from vm.uni-c.dk by dkuug.dk with SMTP id AA09555 (5.65c8/IDA-1.4.4j for ); Wed, 14 Dec 1994 04:08:16 +0100 Message-Id: <199412140308.AA09555@dkuug.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 8270; Wed, 14 Dec 94 04:08:33 DNT Received: from SLACVM.SLAC.STANFORD.EDU by vm.uni-c.dk (Mailer R2.07) with BSMTP id 4271; Wed, 14 Dec 94 04:08:32 DNT Received: by SLACVM (Mailer R2.08 R208004) id 1624; Tue, 13 Dec 94 19:07:41 PST Date: Tue, 13 Dec 1994 19:02 -0800 (PST) From: "Len Moss" To: "SC22/WG5 Mailing List" Subject: Re: (SC22WG5.662) some useful info for X3J3 132 X-Charset: ASCII X-Char-Esc: 29 In-Reply-To: jwagener@amoco.com -- 12/12/94 17:19 AEMallory: please assign this a number and include it in the pre-meeting distribution.AA - - - - - - - - - - - - - C u t H e r e - - - - - - - - - - - - - X3J3/95- 13 Dec 1994 To: X3J3 From: Len Moss Subject: Subset ENABLE Proposal Ref: X3J3/95-026 Floating Point Subset of ENABLE I am no longer a member of the committee, but I have been involved, one way or another, in its deliberations on exception handling for a very long time (going back to the Appendix F version), so I'm going to offer my opinions on this subject one more time (and probably not the last time, either ;-). Despite Jerry's assurances that his subset ENABLE proposal is both short and simple, I believe it would be very unwise to try to slip it into Fortran 95 at this late date. Though the edits are relatively few, their impact on the rest of the standard is major. For example, it uses the notion "processor-dependent" much more freely than in the past, and I believe this will require significant work to clarify. Consider the code fragment, X = 1.1 ENABLE PRINT *, ASIN(X) HANDLE PRINT *, 'Invalid argument for ASIN', X END ENABLE Is this code illegal, or merely processor-dependent? The description of ASIN (13.13.12) says that o/xo/ must be less than or equal to 1. On the other hand, this proposal says that the processor is permitted to detect and signal other exceptions (such as INVALID from the Edinburgh proposal) or to propagate signals from intrinsics, either of which might be grounds for considering this code to be legal but processor-dependent. My point is not that we can't draft words to resolve issues like this, but that it will take time and effort (and probably several tries) to find all such issues and to get the words right. In addition to my concern about the schedule, I also question the extensibility of the proposal. The omission of condition lists from the ENABLE and HANDLE statements will require the use of an awkward syntax if the facility is ever to be extended to something like the Edinburgh proposal. The omission of the condition name from the SIGNAL statement presents a more fundamental problem, however. In his preface to the proposal, Jerry says these "bare" statements are roughly equivalent to the corresponding statements in the Edinburgh proposal with "(FLOATING_POINT)" as the condition. However, in the latter proposal, FLOATING_POINT (or just FLOATING) was a composite condition which was permitted on the ENABLE or HANDLE statements but not on the SIGNAL statement. In order to extend Jerry's proposal to something like the Edinburgh functionality in which SIGNALling conditions can be inquired about, either the standard or the implementor will have to arbitrarily define the meaning of a bare SIGNAL statement; for example, it might become equivalent to "SIGNAL (OVERFLOW,-1)" or perhaps "SIGNAL (UNSPECIFIED,-HUGE(1))". The result will be at best a migration and at worst a portability problem for existing codes. -- Leonard J. Moss o/ My views don't necessarily Stanford Linear Accelerator Center o/ reflect those of SLAC, MS 97; P.O. Box 4349; Stanford, CA 94309 o/ Stanford or the DOE