Prev: scope of implied do-variable and initialize values
Next: Expressive programming for computational physics in Fortran 95+ (paper)
From: glen herrmannsfeldt on 3 Jun 2010 21:40
Craig Powers <craig.powers(a)invalid.invalid> wrote:
(snip)

> Certainly not with non-VALUE arguments, but that's true of just about
> any language I might care to mention; it just becomes obvious with C,
> C++, etc. because they use value arguments so frequently.

PL/I will do it under the appropriate conditions, generating
a temporary and passing that. The value won't be written back
to the original variable, so you have to be careful.

> Although I don't think there's a strong technical reason for it, it does
> not appear that Fortran will do any automatic conversion for numeric
> VALUE arguments.

It makes some sense for BIND(C) VALUE arguments, as C would
do it with a prototype in scope.

> It seems like something that could be put in without
> an obnoxious amount of effort considering that the text of the '03
> standard already says, "If the VALUE attribute is specified, the effect
> is as if the actual argument is assigned to a temporary, and the
> temporary is then argument associated with the dummy argument." (But
> that's in a Note, and the normative text requires that the actual
> argument be type-compatible with non-pointer, non-allocatable dummy with
> no qualifications.)

-- glen
From: Richard Maine on 3 Jun 2010 22:02
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> Craig Powers <craig.powers(a)invalid.invalid> wrote:

>
> > Although I don't think there's a strong technical reason for it, it does
> > not appear that Fortran will do any automatic conversion for numeric
> > VALUE arguments.
>
> It makes some sense for BIND(C) VALUE arguments, as C would
> do it with a prototype in scope.

As noted in other threads, Fortran isn't C. And no, I don't buy the
"this was just for comparison purposes." Sure reads like an explicit
suggestion to put in into Fortran to me.

"C does it" isn't much of a reason to argue that something should be
done in Fortran. It actually has to fit in the Fortran language. Yes,
that is so even for BIND(C) procedures. C does lots of things in
function calls that Fortran doesn't do.

Earlier today or yesterday you were suggesting that something be more
consistent. Now you want to make BIND(C) VALUE arguments behave
fundamentally different from all other arguments, including other
BIND(C) and other VALUE arguments; one has to have both to trigger the
special case? This for no reason other than that C does it? You appear
to have a different notion of consistency than I do.

Do note, by the way, that just because a procedure is BIND(C), that
doesn't mean it is necessarily a procedure written in C.

But I don't know why I bother to post this. It ain't going to happen. No
way. As noted in my other post, it would invalidate existing standard
conforming codes by badly breaking generics. Yes, I'd bet there are
existing codes that use BIND(C) procedures in generics. It is a natural
thing to do. While incompatibilities like that have been known to
happen, they tend to fall into one of 2 classes.

1. The incompatibility was not noticed until after the new standard was
published. Often that isn't even enough, as there have been known to be
errata to fix that kind of problem. Such an unnoticed incompatibility
has more than once been cited as being an adequate reason for an errata.
But this one isn't unnoticed. It wouldn't be unnoticed even if I hadn't
pointed out. It is a glaring big incompatibility.

or

2. There is darn good justification given. Nothing here has been even
close to the kind of justification that tends to be needed. If you think
otherwise, well.... lots of luck. I'll be confident inmy claim that it
ain't gonna happen.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Craig Powers on 3 Jun 2010 22:38
Richard Maine wrote:
> Craig Powers <craig.powers(a)invalid.invalid> wrote:
>
>> Although I don't think there's a strong technical reason for it, it does
>> not appear that Fortran will do any automatic conversion for numeric
>> VALUE arguments. It seems like something that could be put in without
>> an obnoxious amount of effort...
>
> other than completely blowing generics out of the water. :-(
>
> And maybe a few other things, but that one immediately occurs to me.

Oops, yeah, I forgot about that.

C++ manages it, but from what I recall when I followed C++ more closely,
conversion and overload matching rules are a consistent sore point.
There are definitely dragons there, so it would make sense to stay away
with Fortran.
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: scope of implied do-variable and initialize values
Next: Expressive programming for computational physics in Fortran 95+ (paper)