From Keith.Bierman@eng.sun.com Fri Mar 3 06:23:46 1995 Received: from Sun.COM (koriel.Sun.COM) by dkuug.dk with SMTP id AA18522 (5.65c8/IDA-1.4.4j for ); Fri, 3 Mar 1995 23:25:14 +0100 Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA13846; Fri, 3 Mar 95 14:24:52 PST Received: from chiba.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3) id AA25305; Fri, 3 Mar 1995 14:24:45 -0800 Received: by chiba.Eng.Sun.COM (4.1/SMI-4.1) id AA01860; Fri, 3 Mar 95 14:23:46 PST Date: Fri, 3 Mar 95 14:23:46 PST From: Keith.Bierman@eng.sun.com (Keith Bierman-khb@chiba.eng.sun.com::SunPro) Message-Id: <9503032223.AA01860@chiba.Eng.Sun.COM> To: Miles Ellis Cc: SC22WG5@dkuug.dk Subject: (SC22WG5.744) personal submission for the april meeting X-Charset: ASCII X-Char-Esc: 29 There has been a fair amount of discussion about exception handling. I believe that Jerry has, or will have a personal paper on the topic for this meeting. I would like to "speak" for the proposal. Aside from legacy code and similar arguments, the primary reason for many programmers to choose Fortran over competing languages is performance oriented floating point codes. While we should keep performance uppermost in our minds, we ought to also provide as rich (yet portable) set of floating point facilities as we are able...to keep Fortran maximally useful to our core constituency. This is not a new observation, work in this area was authorized at the WG5 meeting in Germany meeting before last, and a lot of work was expended in this area at the last meeting in Scotland. Originally two approaches were proposed, one to provide a low level "goto" like control, very closely related to IEC 559 (aka IEEE 754). The other was "more high level" an exception based direction. Work on the exception based approach seemed to be going well, and had the backing of IFIP 2.5. So as the principal proponent of the other approach, I did not work hard to progress it's work (believing then, as now, that a very good way to get *neither* would be to try to get both). The IFIP group (lead by John) augmented their proposal to handle all sorts of non-numeric issues which members of the committees had raised. Unfortunately this resulted in the proposal being larger and more complicated than some are comfortable with. As a result, X3J3 has chosen to not provide any additional functionality in this area in this release. I consider this seriously unfortunate. F2K will be much too late to provide this functionality. Fortran faces enough hurdles, that not having support for that which is most central to the interests of its core users bodes ill for the future of the language. The X3J11 (ANSI C) committee seems far along with their numerical extensions work. Assuming that things go well for them, C will be a *better* language for numerical programming than Fortran. If they succeed with their "restrict" proposal, Fortran's performance edge will be greatly diminished (restrict tackles the aliasing problem). I belive that WG5 should require a minimal exception handling facility in this release of the language. This may very well entail a delay, as adding even the minimal proposal(s) into f95 will almost certainly require more extensive proofreading than will be feasible at the J3 meeting in Maui. I believe that a little delay now would be worth it. As J3 has voted against this position several times, it should be painfully obvious that I do not speak *for* J3 nor for the US TAG. However this is functionality that is of great importance to my user constituency.