(j3.2006) (SC22WG5.4368) [ukfortran] WG5 informal ballot re Interop. TR

[Malcolm Cohen]

>1. Is the above revised schedule acceptable?

It is certainly better than the previous one.  Some technical aspects of the TR 
continue to be challenging, so I am not completely confident that we have 
relaxed the deadlines enough.

John Reid writes:
>We have two months before the meeting to work on the UTIs, so this should not 
>be a problem.

Sorry but no I don't have two months before the meeting to work on it!  (And 
neither do many other people.)  I don't even have time now to review the 
document properly.

>2. Do you have any comments on N1838?

(0) The way that assumed-type is supposed to work when not in conjunction with 
assumed-rank/shape seems philosophically inconsistent with the way that it works 
in conjunction with assumed-rank/shape.  This seems to lead to either technical 
problems or usage problems.

(1) For assumed-type assumed-rank, passing the type information to the C program 
does not seem to work when the actual argument is assumed-type.

Having the type information for TYPE(*) dummies not working on TYPE(*) actuals 
is just bizarre.  Inclusion of the type field in the descriptor should probably 
be reconsidered.  A reasonable alternative would be to forbid passing TYPE(*) 
actuals to TYPE(*) dummies.  A third alternative would be to require the type 
(and size, see 2) information to be passed around for all TYPE(*) things, but 
that might not meet the interoperability goals.

(2) For assumed-type assumed-rank, passing the element size to the C program 
does not seem to work when the actual argument is assumed-type.

If we really want this field, then either we need to forbid passing TYPE(*) 
actuals to TYPE(*) dummies or to require the compiler to pass the size 
information around.  If we go for the "forbid" route, I hope that we can pass 
CLASS(*) actuals to TYPE(*) dummies - and that if this ends up in a C descriptor 
that the descriptor fields "type" (if we keep that) and "elem_size" (and 
"length" if we get that) are set appropriately.  In fact I think we can do that 
anyway as the TR stands.

(3) I don't understand what the second sentence of 5.2.7p1 is trying to say.

(4) In the past we have always required the TR to give actual edits to the 
standard to implement the extension.  That could well be necessary this time 
around to get the required clarity as to which provisions/rules of F2008 will 
continue to apply and which ones will not.

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