From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Dec 23 20:56:10 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id EEDFB358253; Mon, 23 Dec 2013 20:56:09 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by www.open-std.org (Postfix) with ESMTP id 38EE9356D11 for ; Mon, 23 Dec 2013 20:56:07 +0100 (CET) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBNJu4QC015092 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Mon, 23 Dec 2013 11:56:05 -0800 Subject: Re: (j3.2006) (SC22WG5.5163) [ukfortran] [ Draft corrigendum 3] From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 In-Reply-To: <20131222162956.B9CCF3583E4@www.open-std.org> References: <20131126013542.D88A93582CC@www.open-std.org> <20131220171849.090F03582F4@www.open-std.org> <20131222004843.861D635835A@www.open-std.org> <1387678359.20328.7.camel@van-laptop> <20131222162956.B9CCF3583E4@www.open-std.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Yes Date: Mon, 23 Dec 2013 11:56:04 -0800 Message-ID: <1387828564.13428.329.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-30.el6) Content-Transfer-Encoding: 7bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Sun, 2013-12-22 at 10:29 -0600, Bill Long wrote: > I would not be opposed to moving most of 5.4 into the obsolescent > column. I would rather not see any more stuff moved to the obsolescent column. Do it in textbooks or offline tools. I don't think I'm alone in using well-tested codes that are forty years old. I try to get rid of unreferenced identifiers, which are sometimes signals of mistakes. So it's unhelpful to see a few dozen warnings whizzing by on my screen. I pause the "make" and scroll back and say "Oh, yeah, that's my Newton solver from 1974, complaining that computed GO TO and arithmetic IF are obsolescent." The argument is that computed GO TO ought to be replaced by SELECT CASE. Well, the code is a coroutine. When it suspends, it's supposed to resume after the suspend. The suspend point is frequently inside a loop or an IF construct, or another SELECT CASE construct. You can't get back to it with a SELECT CASE construct without enormous reorganization of the code. The code has been used for nearly forty years. It works well. We haven't discovered any bugs in it for at least thirty years. I'm afraid to make a massive reorganization of it, for fear that it will be ten years before we discover the bugs thereby introduced. In the 1970's and 1980's, Caine, Farber and Gordon were selling a structured Fortran preprocessor called S-Fortran. When Fortran 90 was finally available, there wasn't much use for it (or Ratfor or SFtran or any of the others). But... they also sold a product called the Structuring Engine, that would turn "spaghetti code" into S-Fortran. Unfortunately, that went away also. Are there still any structuring engines available?