while we all know % is the standard delimiter to denote members of derived types, usually the dot is used for that (albeit not standard, or is it now?)
The problem with dot delimiters is that they may lead to ambiguities with dot operators (like .eq.), though Intel compilers seem to cope well
with all of the usual (predefined) comparison operators. (I don't have to recall that blanks always have been "invisible" to Fortran from
the very beginning...)
But what, If I declare my own dot operator?
I have defined an interface operator .eqmm. (which means compared items are equal if nearer than 1 mm, see source example). This can be done
within Fortran 90 standards and compiles in most cases.
But now I have encountered some cases which don't compile.
1) write(*,*) poly.vertex(1).xyz .eqmm. poly.vertex(2).xyz
2) write(*,*) poly_arr(1)%vertex(1)%xyz .eqmm. poly_arr(1)%vertex(2)%xyz
3) write(*,*) poly_arr(1).vertex(1).xyz .eqmm. poly_arr(1).vertex(2).xyz
I'm inclined to agree that case 1 is ambiguous (and indeed the same statement with % as delimiters compiles).
But why doesn't case 2 compile? The only dots involved are those from my .eqmm. definition. Seems the compiler stumbles over the array index poly_arr(1).
Case 3 is what I originally coded. Obviously I expected too much magic from the compiler. (It seems to be well defined and parsable,
as long you don't take the perspective of Fortran and ignore the blanks...)