(j3.2006) J3 Fortran interp letter ballot #14 - due 8-Oct-2007
Whitlock, Stan
stan.whitlock
Fri Sep 7 14:38:44 EDT 2007
J3 - Attached please find the J3 Fortran interp letter ballot #14. It
is due 8-Oct-2007.
Dan - Please give the attached document a paper number in the meeting
#182 directory.
Thanks /Stan
J3/07-xxx
Date: 7-Sep-2007
To: J3 Members
From: interp/Stan Whitlock
Subj: J3 Fortran interp letter ballot #14 - due 8-Oct-2007
Enclosed in the next letter ballot on Fortran interpretations.
The rules by which we operate say:
o J3 votes on the answer at a J3 meeting; a simple majority
vote marks the answer as "passed by J3 meeting".
o Between J3 meetings the chair of /interp sends a J3 letter
ballot to J3 to approve interp answers that have been "passed
by J3 meeting". The letter ballot runs for 30 days. Not
voting on three of four consecutive J3 letter ballots is
grounds to terminate J3 membership. An interp answer passes
by a 2/3rds vote; a no vote must be accompanied by an
explanation of the changes necessary to change the member's
vote to yes.
J3/interp reserves the right to recall an interp answer for
more study even if the answer passes.
9 Fortran 2003 interpretations are currently "Passed by J3 meeting"
after J3 meeting #181. This is the letter ballot phase to go from
"Passed by J3 meeting" to "Passed by J3 letter ballot".
The following Fortran interpretations are being balloted:
Yes No Number Title
--- --- F03/0092 Procedure characteristics and unlimited
polymorphic
--- --- F03/0093 Allocatable array on intrinsic assignment with
scalar expr
--- --- F03/0094 Final subroutine and VALUE attribute
--- --- F03/0095 Bounds remapped pointer assignment and
ASSOCIATED
--- --- F03/0097 Blanks as separators in NAMELIST input
--- --- F03/0098 Does allocate with source= define subcomponents?
--- --- F03/0099 Clause 16 does not account for volatile variable
--- --- F03/0100 Error in field width for special cases of signed
INFINITY output
--- --- F03/0101 Is UDDTIO output suitable for namelist and
list-directed input
The text of these interpretations is attached. Each interpretation
starts with a row of "-"s.
Please mark the above -Y- in the Yes column for "yes", -C- in the Yes
column for "yes with comment", or -N- in the No column for a "no"
answer {be sure to include your reasons with "no"} and send only the
above text {not this entire mail message} with any comments to
j3 at j3-fortran.org
by 11:59:59PM, PST, Monday, 8-Oct-2007, in order to be counted.
Thanks /Stan
----------------------------------------------------------------------
NUMBER: F03/0092
TITLE: Procedure characteristics and unlimited polymorphic
KEYWORDS: Procedure, unlimited polymorphic
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Consider
abstract interface
function foo (x)
class(*) x
class(*), pointer :: foo
end function
end interface
procedure (foo), pointer :: proc_ptr
procedure (foo) proc_tgt
proc_ptr => proc_tgt
According to the rules of procedure pointer assignment at [144:39-41],
proc_ptr and proc_tgt are required to have the same interface
characteristics. However because an unlimited polymorphic entity is not
considered to have a declared type, the rules for characteristics of
dummy data objects [256:26-32] and characteristics of function
results [257:2-8] are not applicable. In addition, rules at [145:5-6]
require that proc_ptr and proc_tgt have the same function return type.
This also does not apply to unlimited polymorphic data.
Is the example intended to be standard-conforming?
ANSWER:
Yes, the example was intended to be standard-conforming.
An edit is provided to clarify this.
The characteristics however are adequately defined. FOO, and thus
both PROC_PTR and PROC_TGT have no type, but are polymorphic; this
precisely characterises an unlimited polymorphic entity. Only the
requirement of type matching in 7.4.2.2 is incorrect.
EDITS to 04-007:
[145:5] After "the same type"
insert " or both be unlimited polymorphic".
SUBMITTED BY: Jim Xia
HISTORY: 07-247 m181 F03/0092 Submitted
07-247r1 m181 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0093
TITLE: Allocatable array on intrinsic assignment with scalar expr
KEYWORDS: allocatable array, intrinsic assignment
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Consider
CHARACTER(:), ALLOCATABLE :: str(:)
ALLOCATE (CHARACTER(1) :: str(0:9))
str = 'reallocate?'
According to the third paragraph of 7.4.1.3, the variable STR should
be deallocated on this assignment because it has a deferred length
type parameter different from the <expr> ('reallocate?'); it should
then be allocated with its length type parameter the same as that of
the <expr> and with the shape and bounds of <expr>. But the STR
cannot be allocated with the shape and bounds of the <expr> since it
is a scalar.
The standard, however, provides a possible interpretation for the
shape of <expr> two paragraphs later where it says
"If <expr> is a scalar and <variable> is an array, the <expr> is
treated as if it were an array of the same shape as <variable>
with every element of the array equal to the scalar value of
<expr>."
Q(1). Should the variable STR be reallocated in this case?
Q(2). If so, what are the values of its length type parameter, shape
and bounds?
ANSWER:
(1) Yes, STR should be reallocated - that is the purpose of the
combination of ALLOCATABLE and deferred type parameters. If
the user does not wish for automatic reallocation he can use
"str(:) = 'do not reallocate'" instead.
(2) The length parameter of str after the assignment is 11 (the value
returned by LEN('reallocate?')). The shape and bounds should be
unchanged. An edit is provided to clarify this.
Note that the standard does not forbid, but does not specify semantics
for,
str = 'oops'
when STR is an unallocated array with a deferred length parameter.
An edit is supplied to make it clear that this is not allowed.
Note also that this applies to parameterized derived types with
deferred type parameters.
EDITS:
[139:22-] Insert new sentence at beginning of paragraph
"If <variable> is an unallocated allocatable array, <expr> shall
be an array."
[139:25] Change "corresponding type parameters of <expr>,"
to "corresponding type parameter of <expr>."
{Note to J3: fix singular/plural correspondence}
[139:25] Before ", with the shape of <expr>"
Insert ". If <variable> is an array and <expr> is scalar it is
allocated with the same bounds as before, otherwise
it is allocated".
{Note to J3: Malcolm thinks it is clear from context what "it" and
"before" mean, but further wordsmithing could be done.}
SUBMITTED BY: Jim Xia
HISTORY: 07-248 m181 F03/0093 Submitted
07-248r2 m181 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0094
TITLE: Final subroutine and VALUE attribute
KEYWORDS: Final subroutine, VALUE
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Currently, the F03 standard allows the VALUE attribute to be specified
for the dummy argument of a final subroutine. This seems to defeat
the purpose of final subroutine, which is intended to apply to the
finalizable entity (the actual argument) itself.
Should the dummy argument of a final subroutine be allowed to have the
VALUE attribute?
ANSWER:
No, the VALUE attribute should not be allowed.
An edit is provided to correct this oversight.
EDITS to 04-007:
[58:14] Replace "not be INTENT(OUT)"
with "not have the INTENT(OUT) or VALUE attribute".
SUBMITTED BY: Jim Xia
HISTORY: 07-249 m181 F03/0094 Submitted
07-249r1 m181 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0095
TITLE: Bounds remapped pointer assignment and ASSOCIATED
KEYWORDS: pointer assignment, bounds-remapping, ASSOCIATED
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
QUESTION:
Case (v) of intrinsic inquiry function ASSOCIATED [305:5-9] says
If TARGET is present and is an array target, the result is true if
the target associated with POINTER and TARGET have the same shape,
are neither of size zero nor arrays whose elements are zero-sized
storage sequences, and occupy the same storage units in array
element order. Otherwise, the result is false. If POINTER is
disassociated, the result is false.
This will cause the intrinsic to return false if the POINTER is pointer
assigned to the TARGET with bounds-remapping (POINTER and TARGET can be
of different ranks). The same issue also exists for case (vii).
Is the POINTER associated with the TARGET if the POINTER is pointer
assigned to the TARGET with bounds-remapping?
ANSWER:
No, it is not intended that ASSOCIATED(POINTER, TARGET) return true
after
pointer assignment using a bounds-remapping that changes the shape or
rank.
This was a conscious decision made in response to a Fortran 90
interpretation
request concerning dummy arguments that are different shaped versions of
the same array in the calling procedure.
EDITS to 04-007:
none
SUBMITTED BY: Jim Xia
HISTORY: 07-259 m181 F03/0095 Submitted
07-259r2 m181 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0097
TITLE: Blanks as separators in NAMELIST input
KEYWORDS: Namelist input, blanks, separators
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
1) Was in intended that blanks be allowed as separators in Namelist
Input?
Consider a namelist input fragment:
I = 3 J = 4
Page 243:5 says that namelist value separators are the same as list
directed value separators. Page 239:7 says those value separators are
"...blanks between values" and then defines what the values are. The
"J" above isn't a value, so the blanks aren't separators and the
fragment is illegal for namelist input
2) Is there a similar problem with namelist comments as in this
fragment?
I = 3 ! this is a namelist comment
ANSWER:
1) Yes, it was intended to allow blanks as separators for namelist
input. Edits are supplied to correct the wording in the standard
2) Yes, there is a similar problem with comments. The fragment is
intended to be legal. The edits correct the error.
EDITS:
[243:5] Replace the paragraph by
"A value separator for list-directed formatting (10.9) is also a
value separator for namelist formatting. In addition, one or more
contiguous blanks between a nonblank value and the following
object designator or "!" comment initiator is a value separator."
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-267 m181 F03/0097 Submitted
07-267r2 m181 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0098
TITLE: Does allocate with source= define subcomponents?
KEYWORDS: allocate, source, define
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Was it intended that an allocate with a source= clause define
subcomponents?
Bullet 11 on 422 says "Successful execution of an allocate STATEMENT
...causes the subcomponent to become undefined."
ANSWER:
An Allocate with a SOURCE= specifier was intended to define
subcomponents.
In fact, none of the lists in clause 16 account for a SOURCE=
specifier. Edits are supplied to clarify this.
EDITS:
[113:21] At the end of the last sentence in 6.3.1.1 insert
"unless they are defined by a SOURCE= specifier"
[421:27-28] 16.5.6, list item 19, modify by adding after
"Allocation of an object", "except by an ALLOCATE statement
with a SOURCE= specifier".
[421:28+] 16.5.6, insert new list item after (19)
"(19a) Successful execution of an ALLOCATE statement with a
SOURCE= specifier causes a subobject of the allocated
object to become defined if the corresponding subobject
of the SOURCE= expression is defined."
[422:41] 16.5.6, list item (11) insert "with no SOURCE= specifier"
after
"ALLOCATE statement"
[422:43+] 16.5.6, add a new list item after (11),
"(11a) Successful execution of an ALLOCATE statement with a
SOURCE= specifier causes a subobject of the allocated
object to become undefined if the corresponding
subobject of the SOURCE= expression is undefined."
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-268 m181 F03/0098 Submitted
07-268r2 m181 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0099
TITLE: Clause 16 does not account for volatile variable
KEYWORDS: volatile, defined, undefined
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Should the various lists in clause 16 that describe definition and
association be modified to include the effects of volatile variables?
In particular, 16.4.2.1.1 through 16.4.2.1.2 do not mention the fact
that pointer association status can be volatile and change by other
means.
16.5.4 says "all other variables are initially undefined.? Can a
volatile variable be initially defined by other means?
16.5 (26) says volatile variables "become defined", but they also can
become undefined, by other means.
Allocatable volatile variables can become allocated or unallocated by
other means also.
ANSWER:
Yes, the lists in clause 16 should be modified to include the effects of
volatility. In addition, the effects of volatile on pointer objects
are not completely specified in clause 5. The effect on allocatable
objects is not complete in clause 6.
EDITS:
[85:10] In the paragraph between note 5.21 and note 5.22, change
"association status and array bounds" to "association status, dynamic
type and type parameters, and array bounds"
[113:21+] Add a new paragraph at the end of 6.3.1.1
"The allocation status of an object with the VOLATILE attribute may
change by means not specified by the program."
[415:27] Add a new paragraph at the end of 16.4.2.1.4
"When a pointer object with the VOLATILE attribute is changed by a means
not specified by the program it may become defined or undefined. In
addition, its array bounds and association status may change. If it is
polymorphic, its dynamic type and type parameters may change."
[421:42-43] 16.5.5 Replace list item (26) with as text, not a list item
"In addition, an object with the VOLATILE attribute (5.1.2.16) might
become defined by a means not specified by the program."
[423:28+] 16.5.6 insert as text after the last list item
"In addition, an object with the VOLATILE attribute (5.1.2.16) might
become undefined by a means not specified by the program."
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-269 m181 F03/0099 Submitted
07-269r2 m181 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0100
TITLE: Error in field width for special cases of signed INFINITY output
KEYWORDS: formatted output, signed infinity
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Is there an error in the description for the output of a IEEE infinity
with a sign and a field width of 3 or 8?
228:36-37 describes the output for an IEEE infinity and special cases
field widths of 3 and 8. But, the special casing doesn't consider the
possibility of a plus or minus sign in the field. A signed infinity
should be special cased for field widths of 9 and 4.
ANSWER:
Yes, there is an error in the special cases. Edits are provided to
correctly describe the required field widths for signed infinities.
EDITS:
[228:36-37] In the paragraph beginning "For an internal value that is
an
IEEE infinity." in 10.6.1.2.1 change "If <w> is less than 3" to
"If no sign is produced and <w> is less than 3".
Add after that sentence:
"If a sign is produced and <w> is less than 4, the field is filled with
asterisks; otherwise, if <w> is less than 9, the sign followed by 'Inf'
is produced. "
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-271 m181 F03/0100 Submitted
07-271r2 m181 Passed by J3 meeting
----------------------------------------------------------------------
NUMBER: F03/0101
TITLE: Is UDDTIO output suitable for namelist and list-directed input
KEYWORDS:UDDTIO, list-directed I/O, namelist I/O
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
The first paragraph of 10.9.2 says that the form of the values
produced by list-directed output is the same as that required for
input. It also says values are separated blanks or commas, etc.
The first paragraph of 10.10.2 has similar words for namelist output.
It also requires that the variable name be produced in upper case and
that the output consist of name-value pairs.
Is it intended that output produced by used defined derived type
routines conform to these rules?
ANSWER:
No, it was not intended to constrain the user derived type output
values. There should be an exception similar to the one for adjacent
un-delimited character values. User derived type output fields do not
need to be readable by either namelist nor list-directed input
EDITS:
[241:5] Add at the end of the paragraph
"The form of the output produced by a used-defined derived type output
routine invoked during list-directed output is specified by the
invoked routine. It need not be compatible with list-directed input
or output."
[246:4] After "and logical values" add ", and output produced by
user-defined derived type output"
[246:7] Add at the end of the paragraph
"The form of the output produced by a used-defined derived type output
routine invoked during namelist output is specified by the
invoked routine. It need not be compatible with namelist input
or output."
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-275 m181 F03/0101 Submitted
07-275r2 m181 Passed by J3 meeting
----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20070907/855d717a/attachment-0001.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 07-xxx LB14.txt
Url: http://j3-fortran.org/pipermail/j3/attachments/20070907/855d717a/attachment-0001.txt
More information about the J3
mailing list