From J.L.Schonfelder@liverpool.ac.uk Wed Jun 22 03:30:36 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA04605 (5.65c8/IDA-1.4.4j for ); Wed, 22 Jun 1994 11:30:37 +0200 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <11669-0@mailhub.liverpool.ac.uk>; Wed, 22 Jun 1994 10:30:23 +0100 Date: Wed, 22 Jun 1994 10:30:36 PDT From: Lawrie Schonfelder Subject: Class of Names Clean-up To: SC22/WG5 members Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Charset: ASCII X-Char-Esc: 29 To: X3J3 and WG5 (30-May-94) From: Lawrie Schonfelder Class of Names Clean-up 1 Introduction It has long been my belief that the class of names definitions in F90 are seriously flawed. They are highly confusing to both novice and experienced Fortran programmer alike. On one hand they fail to represent a number of the restrictions on the use of names that are in fact required by the language, and on the other they have the effect of applying a number of totally unnecessary restrictions. These latter significantly complicate the name management problem for the user for no good linguistic reason. The class of names definitions should be recast so as to apply those restrictions and only those restrictions that are necessary for the correct functioning of the language. In what follows I have attempted to define a set of name classes and rules associated with their definition such that names apply to a unique entity within any class and where the same name identifies different entities in different classes there is always an unambiguous resolution of which entity is involved. 2 Technical Description The main problem is the indiscriminant catch-all definition of class 1 local names. The current definition of class 1 local names, "Named variables that are not statement entities, named constants, named constructs, statement functions, internal procedures, module procedures, dummy procedures, intrinsic procedures, generic identifiers, derived types, and namelist group names" includes construct names, type names and generic procedure names in the same class as variables, constants, specific procedure names, etc. However, the type name is not unique in the class; the type name appears both as the name of the type and as the name of the type value constructor. The control construct name is included in this class in spite of the fact that there is no context in which the construct name could ever be ambiguous with any other local name. Generic procedure names which are by definition not unique in the entities identified are lumped into this same class. At the very least these problems should be fixed. This proposal would place the type names into a separate class (there already exists a rule that says that the set of all accessible types must be uniquely named which is essentially what is meant by a class of name). The constructor name should be considered to be that of a generic function. This is essentially extending the situation that already applies to REAL to all derived types (see paper on constructor enhancements.) {{{ With a relatively trivial extension which provided extra generic function names of CHARACTER, INTEGER, LOGICAL and COMPLEX the whole type conversion/constructor system could be regularised, but I am not proposing this here. }}} Construct names are totally distinguished by context. A name used as a construct name can not be ambiguous with any other use of such a name. In fact the essential scope of a construct name is actually the construct which it identifies. There is no possibility for confusion of a construct name with an other object identified by a class 1 name. As a step in the direction of removing unnecessary restrictions it is proposed that construct names be removed from the class 1 list and placed in a class by themselves. {{{ Note, construct names behave very similarly to statement labels. If at any time we were to allow alphanumeric labels then the class of construct names and labels would be the one requiring local uniqueness. }}} Quite deliberately generic procedure names are names that are intended to identify a number of different specific entities, where the reference necessarily contains other information (arguments) which must serve to disambiguate the reference. Since by definition generic procedure names behave in all sorts of ways that are different from all other names it is hardly surprising if trying to include them within the rules which apply to the use of other names causes problems. There is also the fact that a generic name may also be the same as specific procedure. This again destroys the concept of uniqueness within a class. In a very real sense a generic name is unique within the class of generic names. Since two different definitions of a generic name in different generic interface blocks are concatenated to create the overall overload set identified by the generic name. Only if there is an ambiguous overload involved is there a problem and such programs are by definition illegal. In section 5. there is a statement that is taken over from F77 to the effect that the declaration of a generic name in a type statement is not sufficient to remove the generic property of the name. It appears that this has been taken to mean that if a name is declared in this way and subsequently used in what is clearly a variable reference, the name in fact no longer has the generic property. However, if the name was used as a procedure reference either one that confirms the declared type of one of the other generic references, both procedure references remain valid. For example, REAL :: SIN,x,y COMPLEX :: z ... x=SIN(y) z=SIN((x,y)) is a valid program with both references to SIN being to the generic function SIN. However, if this was slightly modified, REAL :: SIN,x,y COMPLEX :: z ... x=SIN z=SIN((x,y)) so that now the first reference to SIN is to a local variable called SIN. This now results in the second reference becoming invalid, in spite of it remaining entirely unambiguously resolvable as a generic reference to the function SIN with a complex argument. Nothing has in fact changed with respect to the second reference, but it has suddenly become illegal. This behaviour is highly counter intuitive to many experienced programmers let alone being easily explicable to the novice. The standard is seriously unclear about this area and the inclusion of generic names in class 1 does little to help since the text of the standard promptly excludes generic procedure names from the uniqueness requirement anyway. A significant clarification in this area would to treat generic names as an entirely separate category of name subject to their own rules and with a precisely defined relationship with objects in class 1. It is suggested that the essential requirement for the rules should be such that all references made using a particular generic identifier should be unambiguous, but there is no justification for being more restrictive than that. In the above example there is no ambiguity, The entity being referenced by the name SIN in each case is totally distinguished by the context; one is unambiguously a reference to a scalar variable the other is to a generic procedure. A more difficult case could be say the following, REAL,DIMENSION(5)::real,x,y COMPLEX :: z ... x=real(y) y=real(2) z=real((x,y)) The first and last references to real should not cause any problem they are unambiguously references to the generic conversion function real(), the first with a real argument the last with a complex argument. It is the middle reference that is potentially ambiguous. Is this a reference to the array element real(2) or to the generic function converting the integer value 2 to the corresponding real value. Most programmers would I think assume that the array element reference, is what is intended and in such cases this is what should be provided. The variable use should mask the specific clashing function reference. However, it should not as appears to be the current interpretation, mask all generic references and hence render this program illegal. Provided the constructor is classified as a generic procedure, the type names could be classified as forming a class of their own where strict uniqueness would be required and where intrinsic and derived types would form part of the same class; thereby removing another unnecessary irregularity in the treatment of types. Variables of this name would also become possible subject to the same sort of restrictions that apply to variables with the same name as the intrinsic type, c.f. real. 3 Proposed Edits to IS 1539 : 1991 These edits are proposed as an indication to the editorial committee as to the sort of changes that would be necessary to implement these proposals. 3.0.1 14.1.2 [241/23-25] Replace item (1) in the list by the following and renumber the list. (1) named variables that are not statement entities (14.1.3), named constants, statement functions, internal procedures, module procedures, dummy procedures, specific names for intrinsic procedures and namelist group names, (2) named control constructs, (3) type names, intrinsic and derived, (4) generic identifiers, 3.0.2 14.1.2 [241/33] Delete ",except in ...generic names (12.3.2.1)" 3.0.3 14.1.2 [241/35] Before "intrinsic" add "specific" [242/10] After "SIN" add "with a default real argument", before "intrinsic" add "specific" [242/11] Add sentence "A reference with an argument type of complex or any real kind other than the default real still refers to the generic intrinsic functions identified by SIN." 3.0.4 14.1.2.3 [243/13+] Add paragraph If an interpretation of a name exists as a reference to a class 1 entity, this interpretation is used instead of a generic reference via the same name even if such an interpretation was possible. For example, in the following program fragment ... REAL :: REAL(5),X,Y COMPLEX :: Z ... X = REAL(2) Y = REAL(2.0) Z = REAL((X,Y)) ... is a valid program, where X is assigned the value of the second element of the array REAL, Y is assigned the value produced by invoking the generic type conversion intrinsic function REAL with a real argument, and Z is set to the value produced by calling the same generic function with a complex argument. The variant of the generic function that in the absence of the array REAL would convert an integer to a default real, is rendered inaccessible by the declaration of the array. 4 Proposal That the above clarifications of the class of names definitions be included in Fortran 95. -- 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