J3/13-244 To: J3 From: Dan Nagle Date: 2013 February 13 Subject: Proposals for f1x for consideration by WG5 This paper lists proposals for consideration in f1x made by J3 at meetings 199 and 200. Proposal 1 The g0 edit descriptor had a ".d" added in response to public comments as a part of Fortran 2008. The requirement is that ".d" be absent when the list item is not real or complex should be eliminated to make it optional and/or ignored when the list item is not real or complex. A specific behavior should be selected for interpretation of ".d" when used with g0 and the list item is of type integer, logical, or character. Proposal 2 Many edit descriptors have w=0 meaning a "minimum width" field. When a character is printed using 'a' format, often the trim() intrinsic is applied. Since trim() is transformational, it cannot be applied to a whole array, but must be applied to each element individually. Thus, a format descriptor that means "trim the character item and then apply 'a' format" would be useful. This might be called 'a0'. Proposal 3 Processors are required to have the ability to report the appearance of an intrinsic procedure not described in the standard. Fortran 2003 added intrinsic modules. Processors are not required to report the use of non-standard intrinsic modules, nor of non-standard entities from standard intrinsic modules. Doing so would aid standards-conformance checking of programs. Proposal 4 Nested scopes were expanded greatly with f90, and further with f95, f03 and f08. But there is no means to control host association except declaration of a similarly-named entity in the nested scope (at least, for most nested scopes). Thus, a means to specify that a name, names, or all names from the host are not to be available within the nested scope would be helpful. See 13-238 for more. Proposal 5 Interpretation request F08/0038, referencing paper 10-187r1 from meeting 192, requests that specification of DIM= arguments of several intrinsic procedures should be made consistent. This would be helpful to readers of the standard and make the standard's intentions clearer. Proposal 6 An interface block is needed to declare a generic name and its associated specific names in general (that is, outside a type definition). Within a type definition, a generic statement performs the same specification. Allowing a generic statement in more places would be a syntactic convenience. Please see 04-187 and 13-209 for more. Proposal 7 Currently, access control for enumerators requires repetition of the list of names. Allowing access control for enumerators without requiring the repetition of the list of names would be convenient. This might be merely allowing an access-specification on an enumerator statement. Proposal 8 Currently, there is no way to require explicit specification of the external attribute. Providing such a means would aid program checking. Proposal 9 Allow specification functions to have procedure dummy arguments, provided the corresponding actual arguments are not internal. Allow optional dummy arguments of a procedure to be actual arguments to specification functions referenced in restricted expressions, providing the corresponding dummy argument of the specification function is optional. See 13-208r1 for more. Proposal 10 Allow to concatenate characters of different kinds, provided the set of characters of the kind with the smaller set is a subset of the set of characters of the kind with the larger set. See 13-210 for more. Proposal 11 Allow a dummy argument with the VALUE attribute to have the VOLATILE attribute. See 13-211r1 for more. Proposal 12 Allow SIZE= without ADVANCE= on READ statements. See 218r1 for more. Proposal 13 (1) Conditional expressions: based on one or more conditions, a sub-expression is selected for evaluation and the other sub-expressions are not evaluated. This encompasses the functionality of "conditional and" and "conditional not" operations. (2) Conditional arguments: using similar syntax, selecting an actual argument from two or more data objects. This should allow for an object not to be selected in the case of passing to an optional dummy argument. The expression form should be nestable. See 13-234 for more. Proposal 14 We have been thinking about how to respond to IEEE 754 (2008) for some time without making a definite plan, let alone exercising one. We should respond with an update in f1x to make it compatible with the 2008 revision, or clearly understand why we are not doing so. See 13-227 for more. Proposal 15 Add intrinsic functions to test for equality and inequality of bit strings. See 13-230r1 for more. Proposal 16 Move the following intrinsics from part 2 to part 1: (a) the GET functionality should be added as an intrinsic (perhaps with a slightly different name). (b) the SPLIT functionality should be added as an intrinsic. See 13-205r2 for more. Proposal 17 For arrays with more than a few dimensions, it is tedious to specify their bounds in specification expressions individually using existing array intrinsics (for example, size or ubound). Allowing use of an array to specify declared bounds would allow such specification and more. Provide syntax to allow use of an array to specify the bounds of an new array. See 13-216, 13-224, and 13-240 for more.