From Bernard.Pichon@obspm.fr  Tue May  5 19:39:23 1998
Received: from mesiob.obspm.fr ([145.238.2.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id TAA11929 for <sc22wg5@dkuug.dk>; Tue, 5 May 1998 19:39:20 +0200
Received: from pichon.obspm.fr by MESIOB.OBSPM.FR (PMDF V4.2-14 #2584) id
 <01IWOPM43W7K00448V@MESIOB.OBSPM.FR>; Tue, 5 May 1998 19:43:31 +2
Date: Tue, 05 May 1998 19:38:01 +0200
From: Bernard PICHON <Bernard.Pichon@obspm.fr>
Subject: A very important remark about Enhanced Data Type Facilities
To: sc22wg5@dkuug.dk
Cc: Miles ELLIS <Miles.Ellis@etrc.ox.ac.uk>,
        Patrice LIGNELET <lignelet@vcnam.cnam.fr>,
        Michel OLAGNON <Michel.Olagnon@ifremer.fr>,
        Bernard PICHON <Bernard.Pichon@obspm.fr>,
        Arnaud DIQUELOU <arnaud.diquelou@email.afnor.fr>,
        Alain HEBERT <hebert@soleil.serma.cea.fr>
Message-id: <01IWOPM44D6A00448V@MESIOB.OBSPM.FR>
MIME-version: 1.0
X-Mailer: Microsoft Internet Mail 4.70.1161
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7bit
X-MSMail-Priority: Normal
X-Priority: 3

Dear WG5 member,


The french group will meet next thursday (sorry for the very short
delay)
   and WE have a very important question to debate (in OUR humble
opinion)
   concerning the use of the 'allocatable array function results' as
depicted
   in the TR on "enhanced data type facilities in fortran" (my
current
   document on thus subject is numbered N1282).

In fact, WE don't see (from a << practical >> point of view) any code
that
   can use << easily >> this facility. 
For instance, if WE wish use the proposed function
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     

    Integer :: n_size, s
    Logical, Dimension(:), Allocatable :: I_F_O
    ....
    n_size = SIZE( INQUIRE_FILES_OPEN () )      ! step 1)
    Allocate ( I_F_O (n_size) , Stat = s )      ! step 2)
    I_F_O = INQUIRE_FILES_OPEN ()               ! step 3)

[
  note the variant, that we consider as the worst to be done ...)  : 
     Integer :: n_size, s
     Logical, Dimension(1000) :: I_F_O
     ....
     n_size = SIZE( INQUIRE_FILES_OPEN () )      ! step 1)
     I_F_O(:n_size) = INQUIRE_FILES_OPEN ()      ! step 3')
]

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).

Thanks (to answer before thursday... sorry again : Bernard PICHON)

----------------------------------------------------------------------
-----------

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


B) Perhaps, replace (e.g. in foreword line 3 and 6, Section 1 line 2
and 
   last line)      << Fortran >>  by   << Base Fortran >>


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."
                                     ^^

Bernard PICHON