Struggling with dots and % (what should work and what not?)

[markus]

Hello,

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...)

Markus

[Steven_L_Intel1]

I will take a look at these tomorrow. No, the dot is not standard. Our compiler tries to resolve ambiguities in favor of standard-conforming code, but we haven't always gotten it right initially.

[TimP]

Blanks are "invisible" only with fixed format, which has not been the standard for the last 22 years. I don't see that you indicated whether you use fixed or free format. It should be needless to repeat that the use of . where the standard specifies % was an extension which was in use before there were interface defined operators, and it posed some problems even without the newer defined operators. It seems that most source code which has been maintained in the last 2 decades or any code which was intended to be standard or portable would not be using that extension.

[Steven_L_Intel1]

This is .f90 file, so it is free-form. I can reproduce the problems. It turns out this is one we have seen before where the expression is in an I/O list. If you assign the expression to a logical variable and then write that, it works. The issue ID is DPD200236931.

[jimdempseyatthecove]

I think you can also use ()'s write(*,*) (poly_arr(1)%vertex(1)%xyz .eqmm. poly_arr(1)%vertex(2)%xyz) Jim Dempsey

[markus]

Thank you for your responses. But if blanks are significant with free form (what I have learned now), the source should compile. And indeed with encapsulating () it does. Seems to be a parser problem. The reason for preferring nonstandard dots is rather obvious: For the purpose of delimiters they are visually better than %.

[Steven_L_Intel1]

Yes, it is a known parser problem. I will update this thread when I have more information.

[dboggs]

I also hate the dot delimiters. But I understand the issue and have been painfully forcing myself to use % from no on. They are harder to type. They are harder to read. They are harder to say. They are harder to talk about. They are not like every other language. They are ugly. Enough said.