From maine@altair.dfrc.nasa.gov Tue May 5 21:43:48 1998 Received: from altair.dfrc.nasa.gov ([130.134.65.117]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id VAA13798 for ; Tue, 5 May 1998 21:43:46 +0200 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.8.6/8.8.6) id MAA18700; Tue, 5 May 1998 12:42:15 -0700 (PDT) Date: Tue, 5 May 1998 12:42:15 -0700 (PDT) Message-Id: <199805051942.MAA18700@altair.dfrc.nasa.gov> From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bernard PICHON Cc: sc22wg5@dkuug.dk, Miles ELLIS , Patrice LIGNELET , Michel OLAGNON , Arnaud DIQUELOU , Alain HEBERT Subject: (SC22WG5.1502) A very important remark about Enhanced Data Type Facilities In-Reply-To: <199805051739.TAA11942@dkuug.dk> References: <199805051739.TAA11942@dkuug.dk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Bernard PICHON writes: > In fact, WE don't see (from a << practical >> point of view) any code > that can use << easily >> this facility. [allocatable function results] I tend to agree that the utility of allocatable function results is less than that of other of the capabilities added in the TR. But then, this partly reflects inherent limitations in the use of functions. I would tend to code many of these things as subroutines instead of functions. The problem then goes away (with allocatable arguments, which the TR also adds). One could certainly write examples where allocatable function results could be used, but that doesn't mean they will be appropriate for every example. If the function result is used as a primary in an expression where the final result of the expression is of known size, then there is no pre-allocation needed. Your n_size = SIZE( INQUIRE_FILES_OPEN () ) ! step 1) is a simple example of such a case. Yes, I agree that the number of cases where this is what you want is relatively minimal. I can see 3 approaches to this issue 1. Leave it alone, recognizing that allocatable function results are not convenient in all cases, but still would have a few possible applications. 2. Take the capability out completely. Seems to me a bit radical. Why take out something not useful to some cases if others do find it useful in other cases. 3. Most radical. Allow assignment to an allocatable variable to automatically allocate the variable to the appropriate size. This would require working out of several details. It would also be very controversial. This is really a much more general issue than just allocatable function calls. As I recall, we made assignment of structures with allocatable *COMPONENTS* work this way. Seems to me that a proposal to generalize that behavior to direct assignment of allocatable arrays failed. I think that I'll avoid getting into a debate on whether to reraise that issue. > C) Concerning the TR for floating-point exception handlong in > Fortran, > I read in document N1281 (the last I have on this subject : > sorry > if the missprint is already corrected .....) in 15.9.17 (about > IEEE_SET_FLAG subroutine) in the description of the arguement > FLAG_VALUE : > " otherwise, the flag to set to be quiet." > We think (the french group) the followig is better : > " otherwise, the flag is set to be quiet." > ^^ That's still wrong in the f2k draft that I just put out (J3/98-007r1). Its an obvious typo, and I just made it the first and so far only edit added in J3/98-007r2. -- Richard Maine maine@altair.dfrc.nasa.gov