From lindaog@microsoft.com Tue Mar 28 01:55:40 1995 Received: from netmail2.microsoft.com by dkuug.dk with SMTP id AA29955 (5.65c8/IDA-1.4.4j for ); Tue, 28 Mar 1995 20:14:56 +0200 Received: by netmail2.microsoft.com (5.65/25-eef) id AA00823; Tue, 28 Mar 95 10:15:50 -0800 Message-Id: <9503281815.AA00823@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 28 Mar 95 10:15:49 PST X-Msmail-Message-Id: A9F6FB16 X-Msmail-Conversation-Id: A9F6FB16 From: Linda O'Gara To: comp-fortran-90@mailbase.ac.uk Date: Tue, 28 Mar 95 09:55:40 PST Subject: RE: (SC22WG5.773) Pointers to procedures Cc: SC22WG5@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 John Reid writes: I gave a talk on Fortran 90 here at ANU, which has provoked a finite-element expert to ask why we do not have pointers to procedures in Fortran 90. What he most needs is the ability to include procedures as structure components. Lawrie Schoenfelder replies: There are also a number of questions that need thought in introducing procedure variables. Are the dummy argument/keyword names declared with the type and therefore a property of the variable or are they taken from the actual value procedure? How are generic procedures/overload sets handled? How does all this interact with argument passing; getting a seamless upgrade on the current procedure argument functionality will not be trivial? Useful functionality but not easy language design. The analogue from C with simple pointers to an address which happens to be the start address of a proc is not applicable to Fortran. Now me: Pointers to functions are sorely needed for interoperability. Lawrie's right in that we need procedure variables; interoperability could also use arrays of pointers to functions. I disagree with his assessment of the language design issues. The analogue from C is exactly what one wants for interoperability - it is C we generally want to interoperate with. All the other problems he notes ... Well, they might be problems, but WG5 as the requirements body need not worry about that. The implementation body, X3J3, is the proper body to give you feedback on the implementability of a particular item required by WG5. Now me on a soapbox: It has become more and more apparent to me that the users of Fortran use it to get their jobs, science and engineering, done. They need a functional tool to get their jobs done. Functional! If I need to pound some nails, I go to my toolbox in the basement and grope around for my hammer. If the handle happens to have a couple of ugly bumps on it, I don't care as long as I can use it to pound the nails. And, if the bumps don't prevent me from turning the hammer around and using it remove the nails I pounded crookedly, hallelujah! To restate the obvious, we can add wart-y language features to Fortran as long as we don't compromise the functionality.