From malcolm@nag.co.uk Wed May 6 13:05:22 1998 Received: from red.nag.co.uk (red.nag.co.uk [192.156.217.2]) by dkuug.dk (8.6.12/8.6.12) with SMTP id NAA00508 for ; Wed, 6 May 1998 13:05:20 +0200 Received: from sedi8.nag.co.uk by red.nag.co.uk via SMTP (920330.SGI/920502.SGI) for sc22wg5@dkuug.dk id AA25234; Wed, 6 May 98 11:59:51 +0100 Received: by sedi8.nag.co.uk (920330.SGI/920502.SGI) for @red.nag.co.uk:sc22wg5@dkuug.dk id AA21243; Wed, 6 May 98 11:59:49 +0100 From: malcolm@nag.co.uk (Malcolm Cohen) Message-Id: <9805061059.AA21243@sedi8.nag.co.uk> Subject: Re: (SC22WG5.1502) A very important remark about Enhanced Data Type Facilit To: sc22wg5@dkuug.dk Date: Wed, 6 May 1998 11:59:46 +0000 (BST) Cc: ies@nag.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3593 Bernard PICHON said: > In fact, WE don't see (from a << practical >> point of view) any code > that > can use << easily >> this facility. There are several places where this facility can be used without needing to know the shape of the result in advance. The two most obvious are: (a) i/o lists (b) actual arguments The slightly less obvious one is: (c) sub-expressions For example, in C = MATMUL(A,FUN(...)) assuming FUN returns a rank-2 ALLOCATABLE array, only one of the dimensions need be known by the caller - the other disappears in the calculation. (There are lots of other intrinsics that result in one or more dimensions disappearing). > For instance, if WE wish use the proposed function ^^^^^^^^ (I presume) you mean "example". > INQUIRE_FILES_OPEN, > it seems (to our) that WE must > 1) call a first time this function in order to know the > size of the result > 2) allocatable a array of the suitable size > 3) then, assign to this array, the function result Not so. You can do: "PRINT *,inquire_files_open()" without any trouble. You can do: "CALL mysub(inquire_files_open())" without any trouble. But yes, if you want to assign it to a variable of your own, the shape of the result must match the shape of the variable. Some of Richard's suggestions may be germane here for F2002 but are not appropriate for the TR. > Perhaps, WE are in error, (or, worse, WE have understood nothing ...) > but any comment will be appreciated (or, better, a code that > exhibits > a more clever use this facility as a manner that WE haven't seen). Well, ALLOCATABLE function results is, in my opinion, a very minor part of the facility. We would certainly not have bothered to create a TR just for it. However, there is some conceivable use, there *APPEARS* to be no great implementation difficulty, it seems to be more regular to allow it - so I see no reason to disallow it. > Thanks (to answer before thursday... sorry again : Bernard PICHON) I am somewhat confused by this sudden rush - it has been out there for approx three years now - and tomorrow is too late for the JTC1 ballot anyway, since the ballot closed a month ago! In case you are wondering, France voted to Approve, with no comments (see JTC1/N5267). > Here, some minor remarks : > > A) In the same TR, << even >> if the code presented in the final > example > of section 2 is perfectly correct (for the standardization > point of > view), we << prefer >> that the example shows a << more > pedagogical >> > syntax : the lines of the end of the functions/module/program > with the > name of the corresponding function/module/program viz. > END FUNCTION RP_ADD_R > END FUNCTION RP_ADD_RP > END MODULE REAL_POLYNOMIAL_MODULE > END PROGRAM EXAMPLE As this does not appear to be an error of any kind (but rather a matter of opinion w.r.t. style), and no national body raised this issue in the now-closed JTC1 ballot, I do not intend to make these changes to the TR. (I don't think the example appears in the F2002 draft). > B) Perhaps, replace (e.g. in foreword line 3 and 6, Section 1 line 2 > and > last line) << Fortran >> by << Base Fortran >> Thank you, I shall certainly check to make sure that the reference to the F95 standard has the correct title (this only affects one of the above appearances). Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)