[MPI3 Fortran] Agenda for MPI3 Fortran Working group next week

[N.M. Maclaren]

On Jun 4 2009, Aleksandar Donev wrote:
>
>> That is a truly horrible hack!
>
>What is a truly horrible hack? I am puzzled why you are soo inspired to 
>simply write emails that disagree without constructive things to offer 
>in return. I offered at least three options above, and they are all 
>different in subtle ways. ALLOCATABLE components are fundamentally 
>different from pointer ones, especially in regards to what they mean in 
>the context of "copy by value".

Look, Aleks, I explained that in the rest of the paragraph that you snipped.
Here is the context and what I said, with some extra explanation.

% > One way to resolve these issues is to specify that the
% > TYPE(MPI_Communicator) "is an interoperable type", or "does not have
% > pointer and allocatable components", or "does not have allocatable
% > components", etc. One has to decide what to do here. Again, using what
% > we did for TEAMs in coarrays might be useful (but here following the C
% > binding closely might be a better guiding principle).
% 
% That is a truly horrible hack!  The whole point about the semantics of
% communicators is that they DO behave as if they have such components.
% However, I am afraid that the best solution may end up being a horrible
% hack, so I am not saying that your idea shouldn't be considered.

What I was referring to is that, if you express the semantics of 
communicators in terms of the property of a Fortran type, you find that 
they have components that are semantically equivalent to pointers. 
Attributes are obvious, but you can also access all outstanding transfers 
through a communicator, and so on. One common property of ALL the things 
you mentioned is that they don't allow pointer components, and specifying a 
communicator to be like that (when its semantics are such that it has them) 
is necessarily a horrible hack.

>My sole point is that it needs to be specified---just saying "opaque" 
>derived type is insufficient in Fortran (I suspect also in C but I do 
>not know that language well-enough).

I fully agree with that, but was responding to your suggestions of how.
To repeat, I wasn't disagreeing, but was saying that it isn't nice, not at
all.

You are correct about C, and I do.

>> I may have missed another, so please tell me if so.
>
>I believe that what I am thinking of is a "pointer to an incomplete 
>type", but do not have my C book at home today to check. It smells like 
>void* but it is different in some subtle ways, which I likely do not 
>understand.

Ah.  No, that's not a category of types, as such.  It's all rather confused.
I described the three main categories in my previous posting, though 'void'
is not a type at all, let alone an incomplete one.

You won't find an accurate description of C's subtleties in any book that I
have heard of - and even the standards are not enough on their own - you
really need to have been following the standardisation discussions.  I gave
up after C99, so am not in touch with the next one, though I have seen
the proposals.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679