Defined operators and underscore

[rusi_pathan]

What would be a good reason for not allowing underscores in defined
operators? I cannot seem to think of a situation where it can cause
problems or confusion.

For example using "my_plus" instead of "myplus" doesnt work for the
code below:

! --- Module
module my_mod
interface operator(.myplus.)
module procedure my_add
end interface
contains
function my_add(a,b)
implicit none
real, intent(in) :: a,b
real :: my_add
my_add = a + b
end function my_add
end module my_mod

! --- Main Program
program main
use my_mod
implicit none
real :: x,y,z
x = 1.0; y = 2.0
z = 0.0
z = x .myplus. y
print*, z
end program main

[Richard Maine]

rusi_pathan <tabr...@gmail.com> wrote:

> What would be a good reason for not allowing underscores in defined
> operators? I cannot seem to think of a situation where it can cause
> problems or confusion.

I think there was an ambiguity somewhere, though I confess to some
difficulty in concocting an example off the top of my head. Recall that
is isn't just that you can't have underscores. You also can't have
digits.

Let's see. It would have to be some context where one of the dots became
ambiguous as to whether it was part of the operator or some other dot in
the expression. Hmm... Maybe throw in an exponent so that you can get a
letter after a dot. Maybe start with something like 123.e4. and make the
rest "work" if that is parsed as either the number 123.e4, followed by a
dot, or if it is 123, followed by the operator .e4.. Not sure whether
you can get to an ambiguity that way or not, but that's the kind of line
I'd try along... if I were feeling more ambitious at the moment.
Underscores can also be part of literals (the kind designation).

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

[Dick Hendrickson]

Richard Maine wrote:
> rusi_pathan <tabr...@gmail.com> wrote:
>
>> What would be a good reason for not allowing underscores in defined
>> operators? I cannot seem to think of a situation where it can cause
>> problems or confusion.
>
> I think there was an ambiguity somewhere, though I confess to some
> difficulty in concocting an example off the top of my head. Recall that
> is isn't just that you can't have underscores. You also can't have
> digits.
>
> Let's see. It would have to be some context where one of the dots became
> ambiguous as to whether it was part of the operator or some other dot in
> the expression. Hmm... Maybe throw in an exponent so that you can get a
> letter after a dot. Maybe start with something like 123.e4. and make the
> rest "work" if that is parsed as either the number 123.e4, followed by a
> dot, or if it is 123, followed by the operator .e4.. Not sure whether
> you can get to an ambiguity that way or not, but that's the kind of line
> I'd try along... if I were feeling more ambitious at the moment.
> Underscores can also be part of literals (the kind designation).
>

I don't recall the underscore reason either.

The digit restriction isn't "really" an ambiguity. Given something
like
123.e4.xyz blah blah blah

it's "ambiguous" whether .xyx is the start of an operator that has
123.e4 as it's first operand or whether e4 is the operator and 123 is
the left operand. However, for a syntacticly correct blah blah blah
the "ambiguity" eventually goes away. (You don't even need to parse
the whole statement, the ambiguity will be resolved by the time you
reach the next to last token ;) .)

Digits were disallowed in operators essentially because the "ambiguity"
made commercially successful parsers unhappy. I suspect the underscore
was disallowed at the same time. Underscores are similar to digits
(neither is a letter ;) ) and it probably was easier to disallow a
potentially troublesome feature rather than try to prove there were
no problems. Especially since, as Richard said, underscores serve
a different purpose in literal constants.

Dick Hendrickson

[Michael....@sun.com]

If anyone wants a problem which can induce confusion at least, the Sun
compiler accepts the program

INTERFACE OPERATOR(.Efuv.)
FUNCTION IFOO(I,J)
INTEGER, INTENT(IN) :: I, J
END FUNCTION
FUNCTION AFOO(I,R)
INTEGER, INTENT(IN) :: I
REAL, INTENT(IN) :: R
END
END INTERFACE
INTERFACE OPERATOR (.F.)
FUNCTION JFOO(X,I)
REAL, INTENT(IN) :: X
INTEGER, INTENT(IN) :: I
END FUNCTION JFOO
END INTERFACE
REAL :: E6 = 1000.0
print *, 5.E6.F.7
print *, 123.E4_8
print *, 123.Efuv.8
print *, 123.Efuv.E6.F.7
! print *, 123.E4_5.E6.F.7
END

FUNCTION IFOO(I,J)
INTENT(IN) I, J
IFOO = 10000*I + J
END

FUNCTION JFOO(X,I)
REAL, INTENT(IN) :: X
INTEGER, INTENT(IN) :: I
JFOO = 8
END

FUNCTION AFOO(I, R)
INTEGER, INTENT(IN) :: I
REAL, INTENT(IN) :: R
AFOO = 100000.0*I+R
END

I shudder to think how much extra confusion would be possible if the
standard permitted someone to substitute .E4_5. for .Efuv. in
the program! Personally, I don't see the operator in the
commented-out line; to my eyes it looks like a real literal with
a kind number appended.

--Michael Ingrassia