From J.L.Schonfelder@liverpool.ac.uk Tue May 31 10:43:39 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA24876 (5.65c8/IDA-1.4.4j for ); Tue, 31 May 1994 10:43:58 +0200 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <23604-0@mailhub.liverpool.ac.uk>; Tue, 31 May 1994 09:43:40 +0100 From: "Dr.J.L.Schonfelder" Message-Id: <9405310843.AA02564@uxh.liv.ac.uk> Subject: Re: Comments on Parameterized Derived Type proposal (fwd) To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Tue, 31 May 1994 09:43:39 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 10483 X-Charset: ASCII X-Char-Esc: 29 I meant to include wg5 in this reply but did not so I am forwarding it instead. The original text is comments relayed to me by David L. as a result of the last X3J3 meeting. > > I have not had time to reply directly to your comments until now, but > better late than never. > > drlevine wrote > > > > Some comments on the Parameterized Derived Type proposal (X3J3/94-139r1) > > (David Levine, for /oof) > > deleted stuff.... > > > > 1. The type of the type parameters themselves continues to be a worry. > > We've decided (as noted) that only INTEGER will be supported. Yet there > > are no declarations -- or none shown, in any case. > > - if there are no declarations, then we've introduced a new case of > > implicit typing, with its own set of rules. (It was observed that many > > of the example names have a "REAL" appearance: like "wkp") > > - what is the interaction of IMPLICIT NONE with these rules? > > - if the type parameter is declared, then it looks a lot like a > > component of the derived type -- especially for non-KIND parameters, for > > which there is no special attribute keyword. > I think this comment largely misses the point. Once it is decided > that there is a basic default for the nature of a type-param then they are > effectively declared by their appearence in the list on the type definition > statement. Although you could allow or even require them to be declared like > dummy or pseudo components this would be highly unfriendly to users. And > implies a freedom to complicate the functionality which is not being proposed. > However, the proposal to operate with the defaults (integer nonkind) and to > declare the only allowed variation (KIND) is entirely consistent with any > future extension which wishes to allow additional non-default behaviours. > This is not being proposed at this point and the default approach is since > this will cover 99% of any forseeable application. There is NO interaction > with IMPLICIT rules since type-parameters are always explicit. They are not > like procedure dummy arguments in this. > Clearly it would be possible to make them behave exactly like dummy arguments. > But given that the only type possible at present for which a defined use is > being proposed this would be unreasonably complicating the facility for the > user for no good reason. In general, I would not favour declaration exactly > like components either. Whether implemented by an extra pseudo commponent > or not should be an implementation issue. By making a clear didtinction between > type parameters and components this is made more obvious. > > > > > 2. The use of "%%" for attribute inquiry has some unfinished business, > > as well as some controversial aspects. > > > > - Applying "%%" to an "expression", as currently stated, seems to > > produce a confusing parse... one in which the syntactic structure starts > > to be determined by the data type, which is altogether the wrong > > direction. Consider "1 + D%%kp" ... "1+D" is an expression; is that > > the argument to the %% operator? Probably not. > > - The best fix we could find (in the time devoted during meeting 129) > > was to make "%%" apply to a primary. This seems to capture the right > > breadth. It's probably advisable to exclude a function call (just as we > > don't allow component selection on function calls). > > - The grammatical standing of the %% construction itself has not yet > > been defined by the proposal. This is necessary in order to fit this > > into the overall grammar. > In my previous mail I indicated that this was a misunderstanding caused by > the confusion of papers. As per J3 votes at 128 %% is intended to be a > parameter value selector that applies only to a named data-object not to an > expression. > > > > > - In addition, there was still some question about the need for, or > > desireablity of, the double % operator. Would not a single one be > > sufficient? > I think it would be possible for ambiguity to occur in selecting the > parameter value from a component of a structure. > struct%comp%%param is always unambiguous if the %% is replaced by % I > am not convinced. There was also another problem with % that malcolm > cohen spotted but which I can not remember. > However, I still agree with Jerry that the generic inquiry function > with the type-param-name(object) form, generalising the current intrinsic > type behaviour is vastly more desirable. I am still not convinced that the > namespace issue is anything other than the elevation of a minor possible > low probability irritation into an illusory problem. I think the regular > nature of the function form far outweighs any minor name space issues. > > > > 3. The interpretation of "*" as an actual type parameter raised some > > concerns. Though the general intent is clear, the particular member > > [who is usually quite astute] was confused and not certain that the > > various interpretations would all work out correctly. > I do not see any possible problem here at all. A * means assume the value > of this parameter for this dummy argument from the associated actual of the same > type. For not sequence types arguments which must be accessing the same global > typedefinition there is no issue. For sequence types the semantics proposed > require matching of type, parameters and components for the arguments to > be of the same type so again no problem. If there was a problem with sequence > types in this context which is the only area that I could envisage an issue, > the solution would be to disallow parameters on sequence types. > > > > > 4. The form of the constructor is still troubling to some. > > - The analogy with the REAL intrinsic may not be the right answer -- > > REAL takes an OPTIONAL kind parameter, which is appropriately last > > (second) . A constructor with a large number of values would seem > > strange to have the key type parameter(s) (which are not optional) at > > the very end of the list. > Allowing keywords in constructors improves this minor irritation. > Preserving the function reference form of the constructor I see as long term > critical to OOF. > > > > 5. Procedurally, there was a question about the existence of an 004 > > entry on this item. (I've not had a chance to research this). Clearly, > > as a WG5 B9 item, this deserves to move forward regardless. > What has 004 got to do with anything? B9 and the WG5 requirements justtfy > the work procedurally. > > > > 6. There's an interaction with the proposal for allocatable components, > > which should be explored. It's our expectation that there aren't any > > problems, indeed that there's a bunch of useful free functionality > > here... that once the language has parameterized derived types, the next > > step is to provide for allocatable entire derived types rather than just > > the components. > Agreed, but that is what J3 should be spending its time doing. > > > > 7. There is continuing lack of clarity on the value and scope of this > > feature. Additional rationale/explanatory material would be helpful. > > > You cant expect me to accept that! > I will return to this later. I have to go now. > > > (The following discussion does not seem to cover anything very new or > > unknown. Yet in the /oof meeting, we spent over 20 minutes discussing > > these points .. so it's worth some more space) > > > > > > Specifically, people expect that PDT will allow one to save a lot of > > effort on things like the varying string module. ... that one could move > > from old to new, > > > > ! OLD, current formulation > > TYPE VS; ..... CHARACTER datum ; END TYPE > > ! new way of approaching it > > TYPE pVS (char_kind); ...... CHARACTER(kind=char_kind) datum ; END TYPE > > > > That's fine. But in the procedure arena, it's not so simple > > > > ! OLD, current formulation > > function concat (str1, str2); type(VS) concat, str1, str2; > > type(VS) local_var > > ..... end function > > > > As we know, it's not possible to provide the "obvious" generic > > formulation: > > > > generic function concat (str1, str2); type(pVS(*)) concat, str1, str2; > > > > (Though one might expect a certain amount of continuing user confusion here!) > > Instead, you have to do it all out "by hand": > > > > > > ! new way of approaching it > > function concat1 (str1, str2); type(pVS(1)) concat, str1, str2; > > type(kind(str1)) local_var > > ! body of function > > ..... end function > > > > function concat2 (str1, str2); type(pVS(2)) concat, str1, str2; > > type(kind(str1)) local_var > > ! same body as before > > ..... end function > > > > interface concat > > function concat1 (str1, str2); type(pVS(1)) concat, str1, str2; end function > > function concat2 (str1, str2); type(pVS(2)) concat, str1, str2; end function > > end interface > > > > > > The interesting question here ... which ought to be answered in the > > Rationale for this feature ... What Saving is there? > > > > In the old way, I could have done much the same ... written out separate > > procedures and procedure bodies, and a generic interface block. So > > what's new? NOTE that I've saved a little space in the type definition > > (which is probably not too big!) but that I still have to have separate > > copies of the all the procedure bodies, plus a hand-done generic > > interface specification. > > There is one nice gain here, though. Local variables can be > > parameterized based on the type given to some other variable. This > > would appear to slightly ease the job of creating separated generic > > instances. Local variables in the user program, similarly, can be > > specified in a more general way: pVS(kindparm) , maybe even > > pVS(kind=kind(another_vbl)) ... rather than explicitly VS1, VS2, etc. > > Last question in this sequence (about KIND): is this gain enough to > > justify the complexity? True, it makes derived types work like intrinsic > > ones, but are we missing something? > > > > > > > > > > > > ------- > > > > > -- > 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 > > -- 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