(j3.2006) Interop TR: Assumed-size actuals

Malcolm Cohen malcolm
Thu Nov 18 19:09:25 EST 2010


It would be polite to discuss the interop TR on the interop TR mailing list, 
since that includes people not on the J3 mailing list who are nonetheless 
interested parties.

-----Original Message----- 
From: Aleksandar Donev
Date: ?? 22?11?16? 14:04
To: fortran standards email list for J3
Subject: (j3.2006) Interop TR: Assumed-size actuals

Hello,

I finally found some time to look at the draft Interop TR. I can see
that it is a unfinished product, but here are some questions/comments:

1. There is a whole lot of complication with an attempt to allow
assumed-size arrays to be associated as actuals with assumed-rank
dummies. Why is this really important? In particular, we don't go
through such hoops for assumed-shape dummies, so why was it seen as
important to start jumping through hoops now? For the shape, it is said
it is [(size(array,i),i=1,rank(array))]. Should this not be rank-1? What
is the size along the last dimension?

2. An assumed-type dummy shall not correspond to actuals of an "exotic"
derived type (e.g., no type-bound procedures). Is this "dynamic type".
If so, it seems allowed to have a CLASS(*) actual and not be able to
verify anything until run-time: If the dynamic type is indeed exotic no
one will notice and no errors will be generated.

3. There is some weird insistence that  the base_addr, elem_len and
version be in that order?!? Why and if there actually is a good reason
please put a note.

4. 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).

5. Can someone please write an example of the macro CFI_DESC_T. The only
ways I know involve union or malloc and I am not sure they can be used
as type identifiers in declarations. I understand that one can make
CFI_DESC_T(5) expand to some opaque block-of-enough-bytes, but that
defeats the purpose since 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. Seems
extremely clunky to me which is why I was opposed to flexible array members.

6. In the routine CFI_initialize_cdesc, presumably different things
happen depending on whether it is assumed-shape, pointer or allocatable
array, i.e., all the fields are properly initialized?

7. I made the point several times that a routine such as
CFI_cdesc_to_bounds cannot be implemented. It only works for contiguous
objects, since strides do not have to be integer multiples of the
lem_length. At least Bill agreed with me and then promised to take it
out but it is back in again, with unmodified wording.

Thanks,
Aleks

-- 
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

_______________________________________________
J3 mailing list
J3 at j3-fortran.org
http://j3-fortran.org/mailman/listinfo/j3

________________________________________________________________________
This e-mail has been scanned for all viruses by Star.
________________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

-- 
................................Malcolm Cohen, Nihon NAG, Tokyo. 




More information about the J3 mailing list