(j3.2006) Question about co-arrays
Wed Feb 7 19:34:28 EST 2007
Van Snyder wrote:
> In light of Note 5.10 [91:8+1-3], why do we exclude C_PTR and C_FUNPTR
> in C446 [63:26] and C526 [91:6]?
John Reid said:
> We do not allow co-arrays to have the pointer attribute (C546, 98:12).
> C_PTR and C_FUNPTR have the nature of pointers.
No they don't. They have the nature of nonpointer derived types with
pointer components, so Van's comment is quite valid.
C.f. the description of C_LOC.
>the user can do something useful with pointer components
>there is nothing useful that can be done with a C pointer
I find it strange coming from the man who likes to rail against
well-meaning (but unnecessary) restrictions that get in *his* way, that
we should forbid something not for any technical reason but because he
cannot imagine a use for it.
Whether it is true or not, it is not a good reason to forbid something.
(And it's not true either.)
>it makes no sense to claim interop for something that is
>not even part of the C standard
Case (2) of C_LOC already does interop for things that certainly are
not even remotely in the C standard. We added this case at Aleks's
I say again, that's not a technical reason, let alone a good one, for
this restriction, so I don't know why he's changed his philosophy here
(other maybe than that parallel programming is hard, and all the Co-Array
features in the world are not going to change that).
>if ... UPC interoperability, then this issue should be examined again.
I think not. Whatever relevance UPC has to the price of fish in Outer
Mongolia, it has little relevance to C pointers (unless it is being
suggested that we stop being interoperable with C and switch to UPC
If there is no technical justification, C526 should be struck entirely.
Not fiddled with. Not patched. Just deleted. It serves no useful
purpose: one can roll these things up and hide them, so it is
........................Malcolm Cohen (malcolm at nag-j.co.jp), Nihon NAG, Tokyo.
More information about the J3