From J.L.Schonfelder@liverpool.ac.uk Wed Jun 29 06:05:34 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA10405 (5.65c8/IDA-1.4.4j for ); Wed, 29 Jun 1994 14:05:09 +0200 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <01615-0@mailhub.liverpool.ac.uk>; Wed, 29 Jun 1994 13:04:39 +0100 Date: Wed, 29 Jun 1994 13:05:34 PDT From: Lawrie Schonfelder Subject: Re: (SC22WG5.588) generic procedures and section 14.1.2.3 To: SC22WG5@dkuug.dk Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Charset: ASCII X-Char-Esc: 29 Janice raises an interesting issue, and one whih I think needs tidying up by an change to F96 rather thana more restrictive CCI item to F90. I would like to suggest some general principles. 1. The concatenate rule for generic interfaces should apply regardless of how the various parts of the interface are accessed, local definition, use association or host what should be produced is the concatenated interface definition. 2. Having produced the concatenated interface if there is the possibility of an ambiguous reference the generic interface should be illegal regardless of where the specific procedures actually reside or the route they became associated with the generic name. 3. I see no reason why we cannot have both functions and subroutines in the same generic interface. provided the subroutines are unambiguous separately from the functions there cannot be any ambiguity between a function reference and a subroutine call. There are cases where it would be useful to have both a function and a subroutine identified by the same name, e.g. the INSERT, REPLACE etc. functions in the string module could be very much more efficiently implemented as subroutines which modify an argument string rather than return a new modified string. However there are circumstances where the functional programming paradigm is useful and hence the need for the function form. Allowing mixed function and subroutine generic sets would allow both facilities in a convenient package. 4. I would also go further and have local declaration of non-generic entities masking a generic entity only where the local declaration introduced an ambiguity. Summary any generic overload set must be internally unambiguous. A local declaration of a non-generic entity has no effect on the visibility of the generic interface, regardless of means of accessibility, except for perhaps masking the generic reference interpretation if there happens to be an ambiguity. Some of the edits to acheive this are in my paper on class of names, others would be needed though to deal with the subroutine issue. On Mon, 27 Jun 94 18:25:59 EDT Janice Shepherd wrote: > From: Janice Shepherd > Date: Mon, 27 Jun 94 18:25:59 EDT > Subject: (SC22WG5.588) generic procedures and section 14.1.2.3 > To: sc22wg5@dkuug.dk > > Here is a new request for interpretation. Comments would be appreciated. > > David Mattoon: please include this in the X3J3 premeeting distribution. > Thanks. > Janice > > > To: X3J3 > From: Janice Shepherd > Subject: RFI on generic interfaces and host association > > I am submitting the following interpretation request for two reasons: > > 1) there appears to be difference amongst various implementations as to > whether this feature is valid or not, > > 2) at one time interpretation 82 contained the following edit, and > the letter ballot result for that version was 21-3, thus showing > that many committee members agreed with that edit. Since then > the answer to 82 has been simplified to only deal with the specific > question asked, instead of dealing with the larger issue of generic > routines and host association. > The edit was: > In 12.1.2.2.1, insert the following after the sentence containing > the long numbered list: > If the local entity is nongeneric, any entity of the host that > has this name as its generic name is inaccessible. If the local > entity is generic and an entity of the host has this name as its > generic name, the versions of the host entity that would fail > to conform to the rules in 14.1.2.3. if they were made accessible > in the local scoping unit are instead inaccessible. > This edit was part of the reason for adding the comment "see > interpretation 82" to interpretation 99. > > NUMBER: 000180 > TITLE: Unambiguous generic references > KEYWORDS: host association, generic name > DEFECT TYPE: Erratum > STATUS: X3J3 consideration in progress > > QUESTION: Consider the following example: > > SUBROUTINE S() > INTERFACE GEN1 > FUNCTION F1(I) > END FUNCTION > FUNCTION F2(I,J) > END FUNCTION > END INTERFACE > INTERFACE GEN2 > FUNCTION G1() > END FUNCTION > FUNCTION G2(I) > END FUNCTION > END INTERFACE > CALL SS() > CONTAINS > SUBROUTINE SS() > INTERFACE GEN1 > FUNCTION F3(I,J,K) > END FUNCTION > FUNCTION F4(II) > END FUNCTION > END INTERFACE > INTERFACE GEN2 > SUBROUTINE G3() > END SUBROUTINE > END INTERFACE > A = GEN(1,2,3) ! CALL TO F3 > A = GEN(1,2) ! CALL TO F2 > A = GEN(1) ! CALL TO F4 > CALL GEN2() ! CALL TO G3 > END SUBROUTINE > END > > There are rules in section 14.1.2.3 that determine within a scoping > what procedures can have the same generic specification. These rules > directly mention access of a generic procedure via use association, but > they make no mention of generic names accessed via host association. > > There is evidence that the rules in section 14.1.2.3 were not > intended to apply to generic interfaces accessed by host association. > Section 14.1.2.4.1 indicates that a call to a generic name can > be resolved to a generic name in the host if there is the scoping unit > and the host scoping unit both agree that the generic name is the > name of a function or a subroutine. This indicates that in the example > above the definition of 'GEN2' is valid, even though 'G1' and 'G2' > are functions while 'G3' is a subroutine. If the rules set out in > 14.1.2.3 were to apply then the definition of 'GEN2' would be invalid. > > Do the rules in 14.1.2.3 apply to generic procedures accessed via > host association? > > ANSWER: No. The rules in 14.1.2.3 were intended to apply to only ant in > those specific procedures declared to be generic in a scoping unit and > those accessed via use association. An edit is included to clarify > this. > > EDITS: > 1. Add to the end of the first sentence of section 14.1.2.3 > [242:27] > "when the generic interfaces for each of the specific procedures are > declared in the same scoping unit, or accessed via use association." > > 2. Add to the end of the first paragraph of section 14.1.2.3 > [242:32] > "When a generic procedure is accessed from a host scoping unit, > the steps for resolving a procedure reference as described in > 14.1.2.4.1 have the same affect as if the rules restricted > which specific versions from the host scoping unit can be > accessed via the generic reference." > > SUBMITTED BY: Janice C. Shepherd > HISTORY: 94- m130 submitted with suggested answer -- Dr.J.L.Schonfelder Director, Computing Services Dept. The University of Liverpool, UK e-mail J.L.Schonfelder@liv.ac.uk phone: +44(51)794-3716 fax: +44(51)794-3759