From J.L.Schonfelder@liverpool.ac.uk Mon Mar 28 12:49:59 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA05878 (5.65c8/IDA-1.4.4j for ); Mon, 28 Mar 1994 12:50:07 +0200 Received: from 138.253.31.129 by mailhub.liverpool.ac.uk with SMTP (PP) id <24261-0@mailhub.liverpool.ac.uk>; Mon, 28 Mar 1994 11:50:00 +0100 From: "Dr.J.L.Schonfelder" Message-Id: <9403281049.AA21680@uxd.liv.ac.uk> Subject: Re: (x3j3.1994-209) Two new pFRs To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Mon, 28 Mar 1994 11:49:59 +0100 (BST) In-Reply-To: <9403251930.AA19318@newton.ncsa.uiuc.edu> from "Len Moss" at Mar 25, 94 11:22:00 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3444 X-Charset: ASCII X-Char-Esc: 29 Len Moss wrote > > - - - - - - - - - - > > > 050 > Intrinsic and User-defined Specific and Generic Names > <KEYWORDS> INTRINSIC, SPECIFIC, GENERIC, NAMES > <STATUS> Registered > <SUBGROUP> > <TARGET> > <VERSION> 1 > <NOTE> > Proposer's title: "Remove inconsistency in treatment of intrinsic > and user-defined specific and generic names". > </NOTE> > > <REQUIREMENT> > Permit the specific name of a user-defined procedure to be passed as > an actual argument even if it is the same as the generic name, just > as is permitted in Fortran 77 and Fortran 90 for intrinsic functions. > > <PROBLEM DESCRIPTION> > FORTRAN 77 introduced the concept of generic and specific names for > intrinsic functions. It requires that wherever an intrinsic function > name is passed as an actual argument it must be in the form of the > specific name. Thus, when ABS is passed as an actual argument, it is > interpreted as the specific, rather than the generic, name. > > Fortran 90 allows users also to define generic and specific names. > Once again, only specific names may be passed as actual arguments. > However, the penultimate constraint in 12.4.1 [172/7f] categorically > prohibits a generic name being passed as an actual argument. Thus, > if a generic name is identical to a specific name, it cannot be > passed at all as it is interpreted as a generic name. As an example > > <XMP> > subroutine test > INTERFACE f > FUNCTION f(x) > REAL f, x > END function f > END INTERFACE > call thing (f) ! f is generic (as well as specific) > ! and cannot be used > end subroutine test > </XMP> > > is illegal. Thus, there is an inconsistency between the > interpretation of F77-style generic names and of f90-style generic > names. > > The code above should be made legal by interpreting the use of 'f' in > the actual argument to be a specific name. A possible solution is to > add 'unless it is also a specific name' at the end of the penultimate > constraint of 12.4.1 [172/8] in Fortran 90. > > <JUSTIFICATION> > Inconsistencies in the language breach the Principle of Least > Surprise. In dealing with this area of functionality I think the irregularity is not allowing generic dummy procedures. Given we now have the interface block to act as a full declaration of a procedure I see no problem in allowing a declaration of a dummy procedure to be a declaration of a generic name, and the set of legal overloads. It would then be legal to have an actual argument that was generic. The actual argument would have to include in its overload set the overloads defined for the dummy. In the procedure only those overloads defined for the dummy would be accessible via the dummy generic name. I think this area is one that needs cleaning up and very likely some of the arcane restrictions of F77/F90 need to be made obsolescent. Simply extending these restrictions to F2000 does not appear to me to be a good idea. > > <SUBMITTED BY> Michael Metcalf, metcalf@cern.ch > > <HISTORY> > <EVENT> Mar 94: > Proposal submitted via email. > </HISTORY> > > </FORTREQ> > -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk