From rbk@usl.edu  Fri Oct 11 22:48:11 1996
Received: from bp.ucs.usl.edu (root@bp.ucs.usl.edu [130.70.40.36]) by dkuug.dk (8.6.12/8.6.12) with SMTP id WAA24948 for <sc22wg5@dkuug.dk>; Fri, 11 Oct 1996 22:48:07 +0100
Received: from rbk5287.usl.edu (rbk5287.usl.edu [130.70.64.43]) by bp.ucs.usl.edu with SMTP id AA24261
  (5.65c/IDA-1.4.4 for <sc22wg5@dkuug.dk>); Fri, 11 Oct 1996 16:47:43 -0500
Message-Id: <2.2.32.19961011214613.006cc9a4@pop.usl.edu>
X-Sender: rbk5287@pop.usl.edu
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Oct 1996 16:46:13 -0500
To: "Weber C, BSSA" <CHRISTIAN.WEBER@s31.mch1.x400.sni.de>,
        sc22wg5 <sc22wg5@dkuug.dk>
From: "R. Baker Kearfott" <rbk@usl.edu>
Subject: Re: F2000: miscellaneous requirements

Dear Christian,

Thank you for taking the initiative and for doing this necessary 
categorization.  

I have the following comments:

1. I thought "hpc" was charged with dealing with the core of
   scientific computing, that is, with numerical issues in
   addition to high-performance constructs.  Within this framework
   I would judge exception handling, viewed as numerical exception
   handling, to be a part of hpc.  There do not appear to be other
   items, however, in the present list dealing specifically with
   numerical issues (except for one discussed over hpc that I will
   put forward).  I do not feel strongly about where exceptions
   should go, but we should clarify this.

2. Do you view our function as further processing the present list,
   or as identifying additional items?  I thought that the present
   list had more or less already been prioritized.  Or do you view
   our function as doing technical work on the items other than
   those "already treated?"

3. Among the list of "already treated" activities, you listed interval
   arithmetic as a separate TR.  However, the present status is
   "Requirement for Fortran 2000," not as a proposed separate TR.
   Nonetheless, technical work is proceeding fairly intensely on interval
   arithmetic.

Best regards,

Baker


At 09:27 AM 10/10/96 +0200, Weber C, BSSA wrote:
>Dear Fortran Colleagues,
>
>I have tried to categorize the requirements within the 
>repository according to the subgroup missions (see 
>attachment).
>
>Would you - and especially Manuela and Baker as 
>representatives of the other subgroups - please review if 
>you agree with this proposed split of work.
>
>Regards
>Christian
>
>===========================================================
>Christian Weber
>Siemens Nixdorf
>BS2000 SA
>Otto-Hahn-Ring 6
>81739 Munich / Germany
>
>e-mail: christian.weber(a)s31.mch1.x400scn.sni.de
>Tel.:   +49 89 636 49240
>Fax:    +49 89 636 41776
>===========================================================
>
>Christian Weber                                           9th Oct. 96
>Siemens Nixdorf
>OEC BS2000 SA                                      
>
>Dear Fortran Colleagues,
>
>I am currently trying to write the first version of the "Miscellaneous
>Requirements List". 
>
>My approach is 
>- scan the requirements repository (current version),
>- put all requirements there into one of the 5 categories:
>  * "already treated by some TR or dedicated activity", 
>  * "data / interface abstraction", 
>  * "high-performance numerical computing", 
>  * "miscellaneous requirements", and 
>  * "Meta-Requirements" which are guidelines for the standardization 
>     or editing process rather than requirements to be assessed by one 
>     of the three subgroups, 
>- deal further with all requirements within in the "miscellaneous" category
>  (ignoring all the others).
>
>Would you please review if you agree with the categorization (which I
>have done according to my personal judgment) of the requirements which is
>as follows:
>
>1.) Requirements already covered by some TR or dedicated activity:
>=================================================================
>
>6 Conditional Compilation (separate standard part currently voted upon)
>14 Parameterised Derived Types (finished -> part of F2000 anyway)
>14a Kind Parameters for Derived Types          "
>16 Allow ALLOCATABLE derived-type components (separate TR)
>16a Allocatable arrays as dummy arguments    (covered by the above?)
>32 Support IEC 559 conforming or similar hardware (IEEE TR)
>38 Improve Interoperability between Fortran and ANSI C (separate TR)
>38a Improve Interoperability between Fortran and C           "
>62 Interval arithmetic support (separate TR)
>
>2.) Requirements concerning "Better Data / Interface Abstraction"
>=================================================================
>
>11 Aliasing Type Definitions 
>15 Remove name class irregularities 
>17 Derived Type I/O 
>18 Object Oriented Programming 
>41 Renaming of <defined-operator> in USE 
>43 Procedure variables 
>43a Pointers to Procedures 
>44 Regularize Handling of Pointer Arguments 
>44a INTENT for pointers 
>54 Allow <generic-spec>s as actual arguments 
>56 Remove INTENT(IN) requirement for OPERATOR, ASSIGNMENT 
>57 Regularize KIND parametrization intrinsics 
>58 Array Components of Array Structures 
>59 Intrinsic and User-defined Specific and Generic Names 
>72 Extend ALLOCATE to specify non-KIND type parameters 
>74 Additional Visibility Attribute 
>75 Allow PUBLIC entities of PRIVATE type 
>84 Overloading possibility for Pointer assignment 
>85 Operators for more than two arguments 
>87 Requirement for Cleaner iscellaneous Producer in Fortran 90 
>88 Class inheritance and dynamic binding polymorphism 
>89 Constructors and destructors 
>96 Consider an array as a single object; give POINTER attribute to array valued function results 
>
>3.) Requirements concerning "High Performance Numerical Computing"
>==================================================================
>
>19 Standardization of performance directives 
>19a Directives 
>23 Multi-threaded execution facilities 
>52 Asynchronous I/O (proposed HPFF work) 
>53 PRIVATE and SHARED variables for TASK parallelism 
>60 Pointer Association Classes 
>78 Qualifiers and Attributes for High Performance Computing with Fortran 90 79 Recognition of TAB characters in Fortran input
>83 Performance Problem: Allocation and Deallocation 
>
>4.) Miscellaneous Requirements
>==============================
>
>2 Controlling Pointer Bounds 
>5 Exception Handling 
>5a Exception Handling 
>5b Condition Handling 
>5c Exception Handling 
>7 Block Comments 
>20 Command Line Arguments and Environmental Variables 
>21 Bit Data Type, String 
>24 Remove the restriction on the maximum rank of arrays 
>24a Greater than 7 Array Dimensions 
>25 Extend the semantics of the EXIT statement 
>26 Selecting subarrays of non-rectangular form 
>33 Nesting of internal procedures 
>34 Varying length character with declared maximum 
>37 Unsigned INTEGER Data Type 
>42 Allow internal procedures as actual arguments 
>45 Minor Technical Enhancements 
>46 Packaging Implementer Specific Intrinsics in MODULEs 
>47 POSIX Binding to Fortran 90 
>48 Variable Repeat Specifiers in Formats 
>49 Specifying Default Precisions 
>50 Remove limitation on statement length
>51 Annex of processor dependent items 
>55 Regularize RANDOM_SEED functionality 
>61 Generic COUNT_RATE Argument for SYSTEM_CLOCK 
>63 STREAM I/O 
>63a Binary stream I/O 
>63b Non-advancing I/0 combined with free format 
>64 Extend MAX, MIN, etc. to CHARACTER Data Type 
>65 Extend Non-advancing I/O to List-Directed I/O 
>66 Extend Initialization of COMPLEX Variables 
>67 Lower Case Syntax Elements 
>68 Any Kind of Integer for I/O Specifiers 
>69 Permit BOZ constants in the TRANSFER function 
>70 "Clean up" conformance rules 
>71 Allow MERGE in constant expressions 
>72 Extend ALLOCATE to specify non-KIND type parameters 
>73 Named Scratch Files 
>76 Default I/O mode 
>77 New Special Character designations 
>80 Intrinsic 'size' function for derived types 
>81 Instrinsic 'sort' for arrays of intrinsic type 
>82 Intrinsic function 'fft' - Fast Fourier Transformation 
>86 Operation System Support 
>90 Four new elemental intrinsic functions: TRUNCATE, ROUND, IBCHNG,ICOUNT 
>91 PATTERN= in bit manipulation functions such as IBCLR, IBSET, IBCHNG 
>92 Reserved words 
>93 New keywords READ_EOR, READ_EOF, WRITE_EOR (?), WRITE_EOF (?) in INQUIRE statements 
>94 New keywords IS_EOR and IS_EOF in INQUIRE, READ and WRITE statements 
>95 New keywords DEFAULT_READ and DEFAULT_WRITE in INQUIRE statement 
>97 New transformational functions: POSITION and LOCATION
>98 New functions to handle arrays: SCRIPT and SCALAR 
>99 Handling of error messages 
>100 New INTENT attribute: COPY_IN 
>101 New keyword NOCOPY= for functions TRANSFER and RESHAPE 
>102 Primitive graphic facilities in Fortran
>
>5.) Meta-Requirements concerning the standardization process
>============================================================
>
>3 Language Evolution 
>45 Minor Technical Enhancements 
>51 Annex of processor dependent items 
>70 "Clean up" conformance rules 
>
>
>Regards
>Christian
>
>==============================================================
>Christian Weber
>Siemens Nixdorf
>BS2000 SA
>Otto-Hahn-Ring 6
>81739 Munich / Germany
>
>e-mail: christian.weber@s31.mch1.x400scn.sni.de
>Tel.:   +49 89 636 49240
>Fax:    +49 89 636 41776
>==============================================================
>---------------------------------------------------------------
R. Baker Kearfott,       rbk@usl.edu      (318) 482-5346 (fax)
(318) 482-5270 (work)                     (318) 981-9744 (home)
URL: http://interval.usl.edu/kearfott.html
Department of Mathematics, University of Southwestern Louisiana
---------------------------------------------------------------

