From owner-sc22wg5@open-std.org Tue Nov 30 16:58:51 2010 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 0B1EDC3BA0A; Tue, 30 Nov 2010 16:58:51 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 537 seconds by postgrey-1.18 at www2.open-std.org; Tue, 30 Nov 2010 16:58:50 CET Received: from smtp.cims.nyu.edu (SMTP.CIMS.NYU.EDU [128.122.49.100]) by www2.open-std.org (Postfix) with ESMTP id 4E610C3BA03 for ; Tue, 30 Nov 2010 16:58:50 +0100 (CET) Received: from donev.cims.nyu.edu (donev.cims.nyu.edu [128.122.80.20]) (authenticated bits=0) by smtp.cims.nyu.edu (8.14.3/8.13.8) with ESMTP id oAUFnn2F006424 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 30 Nov 2010 10:49:50 -0500 (EST) Message-ID: <4CF51D1D.3090202@courant.nyu.edu> Date: Tue, 30 Nov 2010 10:49:49 -0500 From: Aleksandar Donev User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: WG5 Cc: John.Reid@stfc.ac.uk Subject: Re: (j3.2006) (SC22WG5.4350) WG5 informal ballot re Interop. TR References: <20101108175805.5B97EC178E5@www2.open-std.org> In-Reply-To: <20101108175805.5B97EC178E5@www2.open-std.org> Content-Type: multipart/alternative; boundary="------------070201080003020708090500" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------070201080003020708090500 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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@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@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 --------------070201080003020708090500 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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@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@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
--------------070201080003020708090500--