(j3.2006) (SC22WG5.3731) the interoperability TR - an alternative descriptor design

[Aleksandar Donev]

Hello,

> For DESCRIPTOR, a procedure called from Fortran is invoked in a processor
> dependent fashion.  If the calling sequences are compatible, it might
> be called directly; if not, it would be called via a thunking mechanism
> written in assembler.
I am at a loss as to what to write except that I see absolutely nothing 
good about this proposal, and I see many downsides. I am sure Nick has 
good reasons but they escape me almost entirely.

In particular, the opaqueness of the whole proposal (possible indirect 
calls of unknown overheads, complex structures to describe even trivial 
arguments, etc.) will make it very hard for people to use. The 
functionality gained is mostly academic and does not justify the complexity.

The descriptor TR arose out of *existing* practice and needs programmers 
have expressed. Vendors will tell you that users have often asked for 
the format of their array descriptors so they can thinker with them. For 
example, I have done it and use in my daily codes (I have a 
Descriptors.f90 in my sources). Some vendors have published their 
descriptors in their documentation.

The TR's purpose is to make the job easier for both implementors and 
users. There is one standardized interface to manipulating the array 
descriptors, that each vendor implements. The purpose was NOT to 
manipulate the calling conventions, just simply the fields in an opaque 
array descriptor. I understand it is in some way short sighted because 
it ties to existing practice and not a more general extensible 
framework, but it is PRACTICAL and USEFUL now to lots of programmers. 
Complex designs are not.

Best,
Aleks