From J.S.Morgan@liverpool.ac.uk Fri Apr 12 10:23:57 1996 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk [138.253.100.84]) by dkuug.dk (8.6.12/8.6.12) with SMTP id KAA02432 for ; Fri, 12 Apr 1996 10:23:45 +0200 Received: from chad2-23.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Fri, 12 Apr 1996 09:22:13 +0100 From: "Dr. S. Morgan" Message-Id: <199604120822.JAA23677@chad2-23.liv.ac.uk> Subject: Re: PDT rationale etc... To: Wclodius@aol.com Date: Fri, 12 Apr 1996 09:22:04 +0100 (BST) Cc: sc22wg5@dkuug.dk (sc22wg5 list) In-Reply-To: <960408000000_464622042@emout07.mail.aol.com> from "Wclodius@aol.com" at Apr 8, 96 00:00:02 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 12524 Hello again, Well, it seems Lawrie has answered the mail below fairly comprehensively. It probably won't surprise you that I agree with most of his reply. We discussed it briefly a few days ago. I especially agree that the PDT functionality, as specified in the TR, should not be mixed up with a possible future extension to support templates even though I'd love to see some form of template mechanism in F2000. I also agree with your comments on KIND being a separate type but I don't think we can change things sensibly now. I will modify the TR to take account of your "SELECTED_REAL_KIND" example. I found your comments most welcome and useful. They have served to increased my confidence that the TR can be developed without compromising future OO developments in Fortran, Best wishes, Steve. > > Steve: > > I presume that Schonfelder provided you with copies of my comments on his > proposal circa1994, and that Norman Cohen forwarded my more recent comments. > If not and you are interested in them I could provide you with other copies. > I do have some comments on the draft rationale, etc. > > Other uses of parameterized types in addition to matrixes, include, > "infinite" integers, rational numbers, lists, sets, trees, stacks, etc. > However, some of these uses require that types as well as kind values be > passable as arguments. > > Comments on the rationale: > > On 1.2. The need for KIND type parameters. > > I should note that I currently feel that defining the intrinsic KIND > pararameters as integer parameters with a syntax similar to that of the LEN > parameter was a mistake, and that by following the same path for derived > types the mistake is being compounded. In particular this syntax and > semantics can complicate the implementation of some object oriented features > in Fortran. My concerns arise for several reasons: > > 1. The term parameter usually implies that the dependent variable varies in > a regular fashion on the parameter. There is nothing in the standard that > requires this behavior. Parameter values of 1 and 3 can be associated with > larger entities than values of 2 and 4 respectively, and valid KIND parameter > values can be separated by invalid values. > > 2. One of the advantages of F90 for the user is the ability to employ > encapsulation and data hiding, but the language has not been consistent in > utilizing this capability in its implementation and definition. Associating > KIND parameters with explicit integer values is sometimes a convenience, but > often leads to nonportable coding practices as the various F90 systems are > not consistent in their use of these values. To my mind it would have been > better to define KIND as a seperate non-integer type. > > 3. There are two related, but not identical, ways in which it would be > useful to associate KIND values with derived types. One is as a parameter > that can be used select from different alternatives different types for > selected components, e.g., the current parameterized derived type proposal. > Another is as a selector between different type implementations that > essentially obey the same syntax (or semantics) of another type. The second > useage in particular could provide a basis for implementing flexible object > oriented capabilities. > > The first useage is one way, but not the only way, of defining types that > satisfy the second useage. The current proposal doesn't address other > methods of defining a type that obeys the same syntax. For example, it would > be useful to define matrix types, not only of the simple form given as an > example, but also in other forms used to represent sparse matrices, and use > them as parameters to other types. > > Similarly, the second useage is one way, but an overly restrictive means in > the current proposal, of defining which types can be used as parameters. For > example, it appears to be impossible with this proposal to define a general > linked list type, a typical useage of parameterized types (or modules). In > order to provide such capabilities with a syntax close to the current syntax, > it would be necessary to provide a means of defining new syntaxes with which > to associate KIND values. For example, a generic linked list implementation > would only require the availability of pointer assignments. > > 4. An explicit KIND parameter is one means, but not the only means of > selecting the KIND of a type component. The example code > > TYPE matrix(kind_parameter) > KIND:: kind_parameter > REAL(KIND=kind_parameter) :: m_e(20,20) > END TYPE matrix > > USE matrices > INTEGER, PARAMETER :: K=SELECTED_REAL_KIND(10,50) > REAL(KIND=K) :: R > TYPE(matrix(kind_parameter=K) :: M > > could instead be implemented as > > TYPE matrix(n, m) > REAL(KIND=SELECTED_REAL_KIND(n, m)) :: m_e(20,20) > END TYPE matrix > > USE matrices > INTEGER, PARAMETER :: K=SELECTED_REAL_KIND(10,50) > REAL(KIND=K) :: R > TYPE(matrix(n=10, m=50)) :: M > > However, this will not currently work for LOGICAL or CHARACTER KIND > selection. > > > On 1.3. The need for Non-KIND type parameters > > The F90/95 language has three means of specifying the shape of arrays, > static, allocatable, and automatic. Fixed sized static entities (and > allocatable pointers) are currently allowed as components, simple allocatable > entities and variable sized static components would be allowed under the > current poposal for allocatable components and parameterized derived types, > however, automatic components would simplify code developement considerably > and are not currently addressed by any proposal. It would perhaps be > simplest to incorporate this capability into the syntax of the parameterized > derived type proposal, e.g., > > TYPE(matrix(ord=ORD(transformation_matrix_3D))) :: dummy_matrix_3D > > > On 1.4. Use of KIND statement (X3J3 Concern) > > I have different concerns from X3J3. The current syntax will be slightly > error prone as the user will commonly use similar KIND names and might > through a typographical error use the wrong KIND value in the wrong context. > For the pupose of avoiding this problem and making the code clearer, I would > like to have a syntax of the following form > > KIND(REAL) :: wkp > > i.e., the type name serves as the KIND value for KIND types. > > > On 1.5. Do PDTs meet the time critical criterion for a TR > > No problem here. > > > On1.6. Combinatorial Explosion > > While your analysis does indeed indicate that the combinational explosion > need not be as bad as a simple analysis might indicate, experience with > similar constructs, e.g., C++ templates, Ada's parameterized packages, and > Modula 3's parameterized modules, indicates that it can still be a problem. > Experience also indicates that it remains a useful capability that users > appreciate. > > Note the paragraph > > > "Presumably in most implementations the compiled module would hold > information about what types the different components are and then > allocate space when an object of the type was declared at which time > the kind values would be known" > > is misleading as it implies that the only thing the compiled module lacks > after compilation is information about the size of the objects components. > This will be true only if the components are only parameterized by their > shape, or the compiler generates what most users would view as unacceptably > inefficient code. If any parameters affect the KIND of the components, then > efficiency requires that any operations involving these components be > compiled separately. > > > On 1.7. The PDT feature may be sub-sumed by the OO activities > > While I am not a member of X3J3, I am on the X3J3 OO mailing list and do have > some opinions about the interaction of the parameterized type proposal with > object orientation. I am trying to write an article on the possible > semantics and syntax of constructs that could give object oriented > capabilities to Fortran. This article will address most of these issues as > well as some others, but it is going to take me some weeks to get it into a > form to show to others. This message will have to do untill then. > > It is not only possible that the PDT feature may be sub-sumed by the OO > activities, but even likely, However, having this proposal available at > least prompts others to think about object oriented ideas and lays groundwork > for addressing some of those issues. Therefore, I encourage you to continue, > with the following comments. > > In many ways the current proposal is similar to C++ templates, Modula 3 > parameterized modules, Ada's parameterized packages, SML's functor's etc. > However it has some limitations compared with those constructs. First, it > is not as flexible as those constructs, as it cannot be used to construct > generic linked lists, trees, sets, etc. Second, it's syntax is misleading as > it is not just the components of the type that are affected by the > parameterization, but also many (perhaps all) subprograms defined in terms of > the dummy parameterized type. This is usually made explicit in the other > languages by making the equivalent of Fortran's module the parameterized > object, and not parameterizing the equivalent of Fortran's derived type. > > Of the implementations with related capabilities, the most respected appears > to be SML's functors. Although SML is not an object oriented language, there > are several projects to give it such capabilities, and I understand that one > project in France (Xavier Leroy's?) is furthest along in determining how to > modify functors to make them compatible with those capabilities. If at all > possible I suggest that some of the people involved in this project examine > SML's Functors and the French proposals. > > I also understand that the Theta language project led by Barbara Liskov at > MIT, also has an unusually useful form of module parameterization. As Theta > is an object oriented language, I would encourage someone to examine that > project for its insights. > > > On1.9. Why do we need more than one LEN-type parameter? > > Your comments are good ones. > > > On 1.10. Impact of inquiry functions on namespace > > It is not obvious to me "that every parameter has to have a corresponding > inquiry function defined which corresponds to the name of the parameter." In > many cases the value of the parameter should not be of interest to the user > and having the corresponding inquiry function available violates the spirit > of encapsulation. However, I do feel that having an inquiry function will > often be useful and the rest of the discussion is pertinent. > > > On1.11. Impact on the DIS > > Your comments are good ones. > > > On1.12. Advisability of renaming both the parameter key words > and inquiry function names > > Your comments are good ones. > > > On1.13. The use of * instead of : for dummy nonkind > parameters; most use will be to size arrays > > No comment > > > On1.14. Implicit typing of parameters in the derived type definition > > On this point I essentially have concerns that none of the comments address. > See my comments earlier on the problems with INTEGER KIND values. > > On 1.15. Use more consistent terminology (e.g., shape vs. order) > to aid non-English speakers > > Be more descriptive as you suggest. > > > On1.16. Edits are incomplete (e.g., edits dont allow parameters to > be keyworded in constructors) > > No comment > > > On1.17. Possible ramifications of changing structure constructors > to constructor functions > > Another possible syntax is > > FUNCTION MATRIX(kind,ord) > KIND :: k > INTEGER :: ord > TYPE matrix(k,ord) > REAL(KIND=k) :: m_e(ord,ord) > ENDTYPE > END FUNCTION MATRIX > > which is involved, but perfectly compatible with Fortran's syntax. However, > that syntax is also compatibble with parameterizing modules, subprograms, > etc. > > > On1.18. No edits to chapter 14 regarding potential impact on > namespace > > No comments > > > On 1.19. Justification for the TR > -- --------------------------------------------------------------------- Dr. J. S. Morgan Tel. 0151-794-3746 (3719 for messages) Computing Services Department Fax. 0151-794-3759 The University of Liverpool email. J.S.Morgan @ liverpool.ac.uk P.O. Box 147 Liverpool L69 3BX ---------------------------------------------------------------------