(j3.2006) (SC22WG5.4359) WG5 informal ballot re Interop. TR
Aleksandar Donev
donev
Tue Nov 30 10:49:49 EST 2010
Hello,
My responses:
1. Is the above revised schedule acceptable?
YES
2. Do you have any comments on N1838? Please give special attention
to the UTIs. For each significant change, please provide text for a new
UTI.
Comments:
A) 3.3 paragraph 2 rules out certain actual arguments: derived types
that have type parameters, type-bound procedures, or final procedures.
It should be made clear whether these restrictions apply to the dynamic
type only. Specifically, if the actual is CLASS(*), it seems to me there
is no way to do any safety checking until runtime. Typically this means
people will be using CLASS(*) as a way to bypass the restriction and no
one will notice or complain. I would suggest that polymorphic actuals
corresponding to assumed-type dummies be forbidden entirely.
B) Re UTI TR3: I personally hate the proposed "solution" for characters.
When it
comes to voting again, count me or alternative (1), making elem_len
equal to the character length (and if we do add wchar_t we will have
another type identifier, different from char, so I do not see what the
problem would be).
C) Regarding the macro CFI_DESC_T. Some more specification is needed to
clarify what this macro does, or an explicit form for it provided as an
example. Otherwise one cannot evaluate whether it will be useful in
practice.
Consider
CFI_DESC_T(5) object; // Does object.base_addr work?
Does CFI_DESC_T(5) expand to some opaque block-of-enough-bytes or is it
an actual typed struct?
If so, one can only use the object of type CFI_DESC_T(5) via pointers
and casts, as done in the example in Note 5.2, but one could not in
fact do something like object.base_addr.
D) A routine such as CFI_cdesc_to_bounds cannot be implemented in
general. It only works for contiguous objects, since strides do not have
to be integer multiples of the elem_length. Consider for example an
array of derived type and a data-ref such as
array_of_dt%integer_component. Depending on what the other components of
the derived type and the compiler aligment choices are, one cannot
reverse-engineer the Fortran triplets from the C strides.
The routine CFI_cdesc_to_bounds should be removed.
E) Re UTI 1: I do not like "unlimited polymorphic", and in fact strongly
prefer that it me made very clear assumed type has nothing to do with
unlimited polymorphic. But the standardese may need some more work than
I have time for.
G) Consider the example:
interface
subroutine sub_c(x) bind(c)
type(*),dimension(:) :: x
end subroutine
end interface
subroutine sub(x)
type(*),dimension(*) :: x
call sub_c(x(1:10)) ! What type does sub_c get?
end subroutine
Is the intention that the CFI_type_t field that sub_c gets in its
descriptor be "CFI_type_unspecfi ed"? If so, I suggest that this be made
explicit, that is, there is a rule that explains how the type field in
the descriptor gets filled when the actual is assumed type or, even
worse, polymorphic (see my point A above).
Best,
Aleks
==================
ISO/IEC JTC1/SC22/WG5 N1843
WG5 informal ballot on the schedule and draft of TR 29113
John Reid
This is our schedule for TR 29113 on further interoperability with C,
see N1812:
First draft reviewed by WG5 2010-02
Second draft 2010-10
WG5 ballot 2010-11
PDTR forwarded to SC22 2010-12
PDTR ballot initiated 2011-01
PDTR ballot comments available 2011-04
DTR constructed 2011-06
DTR ballot initiated 2011-07
DTR ballot results available 2011-10
TR published 2011-11
Good progress was made at the October J3 meeting and a second draft is
available as N1838, which is available for WG5 comment. Also available
is N1839, which is a reply to the WG5 paper on Objectives, N1820.
I am very concerned that our schedule does not allow for more serious
work to be done on the draft at the February J3 meeting. Furthermore,
N1838 is not ready for PDTR ballot - for example, it contains 14
Unresolved Technical Issues. I therefore propose that we delay the PDTR
ballot until after the J3 meeting. I have checked with the SC22 Secretary
that we are allowed for this to be a 2-month ballot, which would mean that
the results would still be available for consideration at the June meeting
of WG5. This is my proposed shedule:
N1838 reviewed by WG5 2010-11
Third draft 2011-02
WG5 ballot 2011-02
PDTR forwarded to SC22 2011-03
PDTR ballot initiated 2011-03
PDTR ballot comments available 2011-05
DTR constructed 2011-06
DTR ballot initiated 2011-07
DTR ballot results available 2011-10
TR published 2011-11
I am starting a 4-week informal WG5 ballot on this schedule and on N1838.
Please answer these questions by 9 a.m. UK time on 7 December.
1. Is the above revised schedule acceptable?
2. Do you have any comments on N1838? Please give special attention
to the UTIs. For each significant change, please provide text for a new
UTI.
On 11/08/10 12:57, John Reid wrote:
> Dear WG5,
>
> Please find attached a WG5 informal ballot on the schedule and draft
> of TR 29113. I hope it is self-explanatory. I will send the papers
> that it references, N1838/9, separately.
>
> I hope that members will engage in a lively email debate on the
> Interop TR issues that concern them. It would be helpful if a ballot
> comment provides a summary and conclusion for each such debate.
>
> In addition, I am sure that J3 would welcome draft J3 papers that
> address the Unresolved Technical Issues (UTIs) in N1838.
>
> With best wishes,
>
> John.
>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
--
Aleksandar Donev, Assistant Professor of Mathematics
Courant Institute of Mathematical Sciences
Office: 909 Warren Weaver Hall, New York University
E-mail: donev at courant.nyu.edu
Phone: (212) 992-7315; Fax: (212) 995-4121
Mailing address: 251 Mercer St, New York, NY 10012
Web: http://cims.nyu.edu/~donev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20101130/4d5b1683/attachment.htm>
More information about the J3
mailing list