On 7/8/23 2:23 AM, gah4 wrote:
>> Fortran now has the VALUE attribute for dummy arguments. This does what
>> you are talking about, it requires the compiler to create a modifiable
>> copy of its actual argument. The dummy argument can be changed, while
>> the actual argument is never changed. I think this attribute requires an
>> explicit interface, since both the caller and the callee need to know
>> about it.
>
> Yes. Well, that is also needed to make C interoperability work, in the
> cases where the caller is C. But also, yes, it has to work when both
> are Fortran.

The C interoperability aspect is a different feature, although both use
the VALUE attribute to trigger the behavior. In the C case, the VALUE
attribute for an argument in the interface block determines whether the
address or the value of the modifiable copy is passed to the function.
In the fortran case, it will always be passed by address; it is like
copy-in/copy-out argument association, but without the copy-out step at
the end. So in the C case, it changes how the argument is passed, while
in the fortran case it is syntax sugar for using a variable to make a
temporary copy of the argument, and then ignoring the return value.

As for the idea that this would simplify the programmer's task if it
were the default behavior, I doubt that would be the case. Argument
association in fortran is normally a two-way street, whether it is done
by address association or by copy-in/copy-out. So to have the VALUE
attribute become the default, there would need to be a complicated set
of new rules about when the copy-out step is done and when it isn't. The
current rules and conventions are not complicated, so it is likely best
to leave this convention as is. While it is true that a programmer can
make a rare mistake, it is also true that with declared INTENT, the
compiler can detect many of those mistakes at compile time.

$.02 -Ron Shepard

On Saturday, July 8, 2023 at 10:30:09 AM UTC-7, Ron Shepard wrote:

(snip)

> As for the idea that this would simplify the programmer's task if it
> were the default behavior, I doubt that would be the case. Argument
> association in fortran is normally a two-way street, whether it is done
> by address association or by copy-in/copy-out. So to have the VALUE
> attribute become the default, there would need to be a complicated set
> of new rules about when the copy-out step is done and when it isn't. The
> current rules and conventions are not complicated, so it is likely best
> to leave this convention as is. While it is true that a programmer can
> make a rare mistake, it is also true that with declared INTENT, the
> compiler can detect many of those mistakes at compile time.
I wasn't suggesting that VALUE be the default, but that modifiable
temporaries be used for constants and expressions. I suppose there
is the rare case where a temporary can be used more than once:

CALL X(A+B)
CALL Y(A+B)

a compiler could use the same non-modified temporary variable.

Modifiable temporaries could have been added back to
Fortran 77 or 90 or any since. For expressions, there needs to
be a temporary somewhere. For constants there doesn't, but it
isn't that much more work for the compiler to generate one.

And it does make it just that much easier for the programmer.

Ron Shepard <nospam@nowhere.org> schrieb:
> On 7/8/23 2:23 AM, gah4 wrote:
>>> Fortran now has the VALUE attribute for dummy arguments. This does what
>>> you are talking about, it requires the compiler to create a modifiable
>>> copy of its actual argument. The dummy argument can be changed, while
>>> the actual argument is never changed. I think this attribute requires an
>>> explicit interface, since both the caller and the callee need to know
>>> about it.
>>
>> Yes. Well, that is also needed to make C interoperability work, in the
>> cases where the caller is C. But also, yes, it has to work when both
>> are Fortran.
>
> The C interoperability aspect is a different feature, although both use
> the VALUE attribute to trigger the behavior. In the C case, the VALUE
> attribute for an argument in the interface block determines whether the
> address or the value of the modifiable copy is passed to the function.
> In the fortran case, it will always be passed by address;

This is actually not the case; gfortran chose a different
implementation.

module foo
implicit none
contains
real function add(x,y)
real, value :: x, y
add = x + y
end function add
end module foo

gets you

addss %xmm1, %xmm0
ret

so direct passing in registers is used.

The issue with OPTIONAL, VALUE arguments is solved via a hidden
argument.

gah4 <gah4@u.washington.edu> schrieb:

> I wasn't suggesting that VALUE be the default, but that modifiable
> temporaries be used for constants and expressions. I suppose there
> is the rare case where a temporary can be used more than once:
>
> CALL X(A+B)
> CALL Y(A+B)
>
> a compiler could use the same non-modified temporary variable.
>
> Modifiable temporaries could have been added back to
> Fortran 77 or 90 or any since. For expressions, there needs to
> be a temporary somewhere. For constants there doesn't, but it
> isn't that much more work for the compiler to generate one.
>
> And it does make it just that much easier for the programmer.

What would this bring that is not covered with

no intent
INTENT(IN)
INTENT(OUT)
INTENT(INOUT)
VALUE
INTENT(IN), VALUE

?

On Sunday, July 9, 2023 at 4:04:19 AM UTC-7, Thomas Koenig wrote:

(snip, I wrote)

> > Modifiable temporaries could have been added back to
> > Fortran 77 or 90 or any since. For expressions, there needs to
> > be a temporary somewhere. For constants there doesn't, but it
> > isn't that much more work for the compiler to generate one.
> > And it does make it just that much easier for the programmer.
> What would this bring that is not covered with
> no intent
> INTENT(IN)
> INTENT(OUT)
> INTENT(INOUT)
> VALUE
> INTENT(IN), VALUE
It could have been added before INTENT, but wasn't.

It could still be added for the no intent case, and for the INTENT(INOUT) case.

In both cases, it indicates ignoring of any returned (modified) values.

There are some cases, maybe not so many, when an argument needs to
be passed, constant or expression, but any changed value isn't needed.

That is, it is in some cases but not all cases.

One could write separate subroutines for the two, but that is extra work.

One could write ENTRY points, but those are deprecated.

gah4 <gah4@u.washington.edu> schrieb:
> On Sunday, July 9, 2023 at 4:04:19 AM UTC-7, Thomas Koenig wrote:
>
> (snip, I wrote)
>
>> > Modifiable temporaries could have been added back to
>> > Fortran 77 or 90 or any since. For expressions, there needs to
>> > be a temporary somewhere. For constants there doesn't, but it
>> > isn't that much more work for the compiler to generate one.
>
>> > And it does make it just that much easier for the programmer.
>> What would this bring that is not covered with
>
>> no intent
>> INTENT(IN)
>> INTENT(OUT)
>> INTENT(INOUT)
>> VALUE
>> INTENT(IN), VALUE
>
> It could have been added before INTENT, but wasn't.
>
> It could still be added for the no intent case, and for the INTENT(INOUT) case.
>
> In both cases, it indicates ignoring of any returned (modified) values.

How is that different from VALUE?

On Monday, July 10, 2023 at 12:27:09 AM UTC-7, Thomas Koenig wrote:
> gah4 <ga...@u.washington.edu> schrieb:
> > On Sunday, July 9, 2023 at 4:04:19 AM UTC-7, Thomas Koenig wrote:

(snip)

> >> What would this bring that is not covered with
> >
> >> no intent
> >> INTENT(IN)
> >> INTENT(OUT)
> >> INTENT(INOUT)
> >> VALUE
> >> INTENT(IN), VALUE
> > It could have been added before INTENT, but wasn't.
> > It could still be added for the no intent case, and for the INTENT(INOUT) case.

> > In both cases, it indicates ignoring of any returned (modified) values.

> How is that different from VALUE?

If you call with a variable, you get the changed value.

With a constant, expression, or variable in parentheses, the latter being
a form of expression, you don't get the new value.

Le 10/07/2023 à 09:50, gah4 a écrit :
> On Monday, July 10, 2023 at 12:27:09 AM UTC-7, Thomas Koenig wrote:
>> gah4 <ga...@u.washington.edu> schrieb:
>> > On Sunday, July 9, 2023 at 4:04:19 AM UTC-7, Thomas Koenig wrote:
>
> (snip)
>
>> >> What would this bring that is not covered with
>> >
>> >> no intent
>> >> INTENT(IN)
>> >> INTENT(OUT)
>> >> INTENT(INOUT)
>> >> VALUE
>> >> INTENT(IN), VALUE
>
>> > It could have been added before INTENT, but wasn't.
>
>> > It could still be added for the no intent case, and for the INTENT(INOUT)
>> case.
>
>> > In both cases, it indicates ignoring of any returned (modified) values.
>
>> How is that different from VALUE?
>
> If you call with a variable, you get the changed value.
>
> With a constant, expression, or variable in parentheses, the latter being
> a form of expression, you don't get the new value.

The whole intent of INTENT() was to enable more compile-time error
detections. If a constant or an expression is given as the actual argument
when the dummy argument has INTENT(OUT) the compiler can infer this is an
error.

I get what you mean, for an INTENT(INOUT) dummy sometimes you are not
interested in the returned value, so passing a constant or an expression
could do. But at the end here it would mean less possible error detections
by the compiler.

I think the way to properly manage that with the current rules is to have
2 arguments instead of one: an "INTENT(IN), VALUE" dummy where you can
pass whatever you like, and an INTENT(OUT), OPTIONAL dummy for the return
value if desired. "VALUE" is important here to prevent aliasing in the
case the two actual arguments are the same object (but one should check if
it is permitted by the standard, anyway).