From J.L.Schonfelder@liverpool.ac.uk Tue May 31 12:00:07 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA29651 (5.65c8/IDA-1.4.4j for ); Tue, 31 May 1994 12:00:31 +0200 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <02849-0@mailhub.liverpool.ac.uk>; Tue, 31 May 1994 11:00:09 +0100 From: "Dr.J.L.Schonfelder" Message-Id: <9405311000.AA05361@uxh.liv.ac.uk> Subject: Re: Comments on Parameterized Derived Type proposal To: drlevine@apollo.hp.com (drlevine) Date: Tue, 31 May 1994 11:00:07 +0100 (BST) Cc: SC22WG5@dkuug.dk (SC22/WG5 members) In-Reply-To: <9405101815.AA14315@hplb.hpl.hp.com> from "drlevine" at May 10, 94 02:09:32 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5863 X-Charset: ASCII X-Char-Esc: 29 drlevine wrote deleted stuff... > > 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. The proposal here is essentially the same as for character. The functionality is necessary and needs to be as per the intrinsic types. For a character dummy argument to assume its length from the associated actual argument the actual length of the dummy argument is specified as a *. SUBROUTINE SUB1(ch) CHARACTER(LEN=*) :: ch IF we had TYPE VECTOR(order) REAL,DIMENSION(1:order) :: comp ENDTYPE VECTOR the corresponding declarations would be SUBROUTINE SUB2(vec) type(VECTOR(order=*)) :: vec which indicates that the dummy argument vec assumes it order from the associated actual argument. To declare local variables of the same order you would need to write type(VECTOR(order=order(vec))) :: local_vec or type(VECTOR(order=vec%%order)) :: local_vec depending how the issue of type-parameter value inquiry is resolved. I do not see what the supposed problem is! more deleted stuff... > > 7. There is continuing lack of clarity on the value and scope of this > feature. Additional rationale/explanatory material would be helpful. > > (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. In the case of KIND parameterisation the module writer must provide explicit overloads for the various kinds available on the processor. (much as the compiler writer must provide facilities associated with the various representations sepected by KIND for he intrinsics.) If I am writing a library of procedures that are generic over precision on a two precision real system I will have to write two specific procedures. If I am porting or working on a system with three kinds of real to provide full generic support for the user I will need to provide three specific procedures (at least). The KIND parameterisation of reals makes it simpler to generate the additional source code but I still have to produce the extra code in my module. The user on the other hand obtains more substantial gains. Provided the interface presented to him/her is generic names only the user code can be parameterised and moved between the systems without the programs having to be aware of the extra specific procs in the one case. This functionality is needed also for derived types particularly if they are to be used in conjunction with intrinsic types such as above. The major gain comes from the nonkind parameters. The above vector type could not be written without parameters. As things are now we have the Pascal disease. A vector has to have its order fixed in the definition of the type and if we want a vector of a differnt order we would need to write a new module. > 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? > My answer is YES. Try to write modules that are generic over KIND and some parameter like order without parameterised types. It cant be done! > -- 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