shouldn't VALUE parameters act like assignments for type-conformance purposes?
Steven G. Johnson
the dummy argument (i.e. same type, for nonpolymorphic types). So you
can't pass e.g. an INTEGER variable to a function expecting a REAL
parameter. This makes a lot of sense for traditional Fortran pass-by-
reference(-like) semantics.
However, Fortran 2003 added a VALUE attribute, to allow passing
arguments by value. NOTE 12.22 in the standard suggests that the
intention was that "the effect is as if the actual argument is
assigned to a temporary, and the temporary is then argument associated
with the dummy argument."
If the actual argument were assigned to a temporary first, however,
then the type wouldn't need to be compatible, it would only need to be
"conformant" in the sense of assignment statements (section 7.4.1.2).
So, for example, it would be possible to pass an INTEGER actual
argument to a REAL, VALUE dummy argument. This behavior seems like it
would make a lot of sense -- there is no apparent technical reason why
VALUE parameters need to be anything other than assignment-conformant,
and assignment-conformance is all that is required in other languages
(C and friends) that traditionally pass by value.
Nevertheless, the standard seems not to support this, since a literal
reading of the type-compatibility requirements (section 12.4.1.2)
makes no explicit exception for VALUE arguments. gfortran, for
example, requires strict type compatibility even for VALUE arguments.
Of course, one can work around this by explicitly declaring a
temporary variable and doing the assignment, but isn't part of the
point of VALUE parameters that you shouldn't have to do this?
What was the intention of the standards committee here? Is this a
defect in the standard?
Regards,
Steven G. Johnson
Richard Maine
> Normally Fortran's actual arguments have to be type compatible with
> the dummy argument ...
> However, Fortran 2003 added a VALUE attribute,
> If the actual argument were assigned to a temporary first, however,
> then the type wouldn't need to be compatible, it would only need to be
> "conformant" in the sense of assignment statements (section 7.4.1.2).
> So, for example, it would be possible to pass an INTEGER actual
> argument to a REAL, VALUE dummy argument. This behavior seems like it
> would make a lot of sense -- there is no apparent technical reason why
> VALUE parameters need to be anything other than assignment-conformant,
> and assignment-conformance is all that is required in other languages
> (C and friends) that traditionally pass by value.
>
> Nevertheless, the standard seems not to support this, since a literal
> reading of the type-compatibility requirements (section 12.4.1.2)
> makes no explicit exception for VALUE arguments. gfortran, for
> example, requires strict type compatibility even for VALUE arguments.
> Of course, one can work around this by explicitly declaring a
> temporary variable and doing the assignment, but isn't part of the
> point of VALUE parameters that you shouldn't have to do this?
>
> What was the intention of the standards committee here? Is this a
> defect in the standard?
If VALUE were made an exception to the usual type compatibility
requirements, there would have to be a bunch of other exceptions made
elsewhere to support it. I'm quite confident that there was no intent to
make such an exception in f2003. As to a possible future language
enhancement, that's not quite the same question, but I suspect you'd
have a hard time selling it mostly because of the exceptions required.
In particular, consider the effect on generic resolution. I won't say
that one couldn't integrate such a feature into generic resolution, but
that's already one of the messier parts of the language. Fortunately,
the cases of generic resolution that most often come up are simple and
obvious. (There's only one procedure around that fits and you use it).
But I know of no short way to even describe the complete rules for the
general case; you just have to plow through that part of the standard
line by line. I would guess that adding extra complications to it would
be a hard sell.
An issue related to generic resolution is the restrictions on the set of
specific procedures that are allowed to be in the same generic. Those
restrictions often confuse people because, for the sake of relative
simplicity, they are more restrictive than absolutely needed. Please
note the "relative" modifier. The rules are pretty messy. (I have never
figured out one niggly bit myself). They just aren't as messy as would
be needed to allow everything that could plausibly be alowed.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
glen herrmannsfeldt
> Steven G. Johnson <ste...@alum.mit.edu> wrote:
>> Normally Fortran's actual arguments have to be type
>> compatible with the dummy argument ...
>> However, Fortran 2003 added a VALUE attribute,
>> If the actual argument were assigned to a temporary first, however,
>> then the type wouldn't need to be compatible, it would only need to be
>> "conformant" in the sense of assignment statements (section 7.4.1.2).
Yes, it should be possible, but so far it isn't allowed.
It could also be done for INTENT(IN) for similar reasons.
>> Nevertheless, the standard seems not to support this, since a literal
>> reading of the type-compatibility requirements (section 12.4.1.2)
>> makes no explicit exception for VALUE arguments.
(snip)
>> What was the intention of the standards committee here? Is this a
>> defect in the standard?
> If VALUE were made an exception to the usual type compatibility
> requirements, there would have to be a bunch of other exceptions made
> elsewhere to support it. I'm quite confident that there was no intent to
> make such an exception in f2003. As to a possible future language
> enhancement, that's not quite the same question, but I suspect you'd
> have a hard time selling it mostly because of the exceptions required.
> In particular, consider the effect on generic resolution.
Java does it with pretty reasonable rules. Similar rules would
probably also work with Fortran. If the compiler can find a
non-ambiguous method, then it is allowed, otherwise not.
> I won't say
> that one couldn't integrate such a feature into generic resolution, but
> that's already one of the messier parts of the language. Fortunately,
> the cases of generic resolution that most often come up are simple and
> obvious. (There's only one procedure around that fits and you use it).
> But I know of no short way to even describe the complete rules for the
> general case; you just have to plow through that part of the standard
> line by line. I would guess that adding extra complications to it would
> be a hard sell.
Note that PL/I allows passing arguments of different type, even
without call by value. (A copy is passed, and you don't get the
result back. Most often it is needed for constants.)
-------------------------------------
PL/I doesn't have KIND like Fortran. Each different base, precision,
and scale counts as a different type, and constants have the base,
scale, and precision they are written in.
The constant 1 is FIXED DECIMAL(1,0). It is useful to be able to
pass 1 as an argument to a routine expecting, for example,
FIXED BINARY(31,0), and PL/I allows it. In the case of variables,
the compiler usually gives a warning. 1e0 is FLOAT DEC(1), and can
be passed to FLOAT DEC(6) or FLOAT BIN(53), or pretty much any
other type. PL/I would be very hard to use without such conversion.
-- glen
Richard Maine
> Richard Maine <nos...@see.signature> wrote:
> > Steven G. Johnson <ste...@alum.mit.edu> wrote:
>
> >> Normally Fortran's actual arguments have to be type
> >> compatible with the dummy argument ...
>
> >> However, Fortran 2003 added a VALUE attribute,
>
> >> If the actual argument were assigned to a temporary first, however,
> >> then the type wouldn't need to be compatible, it would only need to be
> >> "conformant" in the sense of assignment statements (section 7.4.1.2).
...
> > If VALUE were made an exception to the usual type compatibility
> > requirements, there would have to be a bunch of other exceptions made
> > elsewhere to support it.
> > In particular, consider the effect on generic resolution.
>
> Java does it with pretty reasonable rules. Similar rules would
> probably also work with Fortran. If the compiler can find a
> non-ambiguous method, then it is allowed, otherwise not.
So completely change the philosophy about how Fortran generic resolution
works? And do so just for the sake of this one feature? Good luck
selling that. :-) I'm sure it is "possible" to make such a thing work.
Selling it is another matter.
Note that a basic feature of Fortran generics is that the ambiguity
checking is basically done when the generic is built, without needing to
look at any particular reference to the generic. There is no need to
check for ambiguity of a particular reference, as it is guaranteed
beforehand that there can't be such ambiguity. Thus, for example, if you
have a generic in some module, you find out about any potential problems
when compiling the module; you don't have to check what you think are
all possible ways to reference the generic, only to discover later that
one of the users of your module used a way that you hadn't thought of.
Your user will never see an error message about an ambiguous reference;
you handle that beforehand. That's what I'm refering to when I say that
it is a change in philosophy.
I'm not going to argue about which philosophy is "better". I just note
that it would be a change. Changing a philosophical approach like that
tends to be a bigger deal than adding a feature... and thus harder to
sell.
> Note that PL/I allows passing arguments of different type, even
> without call by value. (A copy is passed, and you don't get the
> result back. Most often it is needed for constants.)
I won't get into a language war (as in, I won't reply further to this
aspect), but I always found that particular feature of PL/I to be a
pain. I'd make a mistake in referencing a procedure and instead of
giving me a compilation error, it would run and do... something.... but
nothing at all close to what I had in mind. This typically happened to
me in cases where the arguments were just completely FUBAR in ways that
the compiler's conversion was not going to help. For example, I'd have
the arguments in the wrong order or some such thing.
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Richard Maine <nos...@see.signature> wrote:
>> > Steven G. Johnson <ste...@alum.mit.edu> wrote:
>>
>> >> Normally Fortran's actual arguments have to be type
>> >> compatible with the dummy argument ...
>>
>> >> However, Fortran 2003 added a VALUE attribute,
>>
>> >> If the actual argument were assigned to a temporary first, however,
>> >> then the type wouldn't need to be compatible, it would only need to be
>> >> "conformant" in the sense of assignment statements (section 7.4.1.2).
>...
>> > If VALUE were made an exception to the usual type compatibility
>> > requirements, there would have to be a bunch of other exceptions made
>> > elsewhere to support it.
>
>> > In particular, consider the effect on generic resolution.
>>
>> Java does it with pretty reasonable rules. Similar rules would
>> probably also work with Fortran. If the compiler can find a
>> non-ambiguous method, then it is allowed, otherwise not.
>
>So completely change the philosophy about how Fortran generic resolution
>works? And do so just for the sake of this one feature? Good luck
>selling that. :-) I'm sure it is "possible" to make such a thing work.
>Selling it is another matter.
It would have been fairly simple, actually, when VALUE was first
perpetrated. I agree that it would have been totally different to
the rest of Fortran's type handling in procedures, and not just in
generic resolution.
I think that this whole area of Fortran, VALUE, argument passing
and type handling in procedures, is a mistake. But there just
wasn't any experience in 1958, and was almost none on generic
procedures in 1977 - yes, they were a decade older, but had not
really has much use in real code. And Fortran 90 and 2003 didn't
want to be incompatible ....
>> Note that PL/I allows passing arguments of different type, even
>> without call by value. (A copy is passed, and you don't get the
>> result back. Most often it is needed for constants.)
>
>I won't get into a language war (as in, I won't reply further to this
>aspect), but I always found that particular feature of PL/I to be a
>pain. I'd make a mistake in referencing a procedure and instead of
>giving me a compilation error, it would run and do... something.... but
>nothing at all close to what I had in mind. ....
As distinct from Perl, where that applies even to making syntax
errors!
More seriously, PL/I had many interesting features, but it was
the archetypical committee camel, and it was nearly as hard to
avoid tripping over its gotchas as it is in ISO C. If you want
a language that got type conversion of procedure arguments right
(though only for the built-in types), look at Algol 68.
If I were designing a language, one of the constructs would be
specified type conversions, which would be applied automatically.
And the compiler would check that they formed a DAG and there
were no ambiguities, statically. It could be done, and would
be efficient in all but lunatic cases.
But I agree that starting from Fortran and going there would not
be a journey that I would want to take!
Regards,
Nick Maclaren.
glen herrmannsfeldt
(snip regarding conversion of procedure arguments)
>> Java does it with pretty reasonable rules. Similar rules would
>> probably also work with Fortran. If the compiler can find a
>> non-ambiguous method, then it is allowed, otherwise not.
> So completely change the philosophy about how Fortran generic resolution
> works? And do so just for the sake of this one feature? Good luck
> selling that. :-) I'm sure it is "possible" to make such a thing work.
> Selling it is another matter.
If it can't be done and maintain back compatibility, then it can't
be done. For the cases not allowed now, it would seem that it could
be added.
> Note that a basic feature of Fortran generics is that the ambiguity
> checking is basically done when the generic is built, without needing to
> look at any particular reference to the generic. There is no need to
> check for ambiguity of a particular reference, as it is guaranteed
> beforehand that there can't be such ambiguity.
As examples of what Java allows, if you have a method such as
public static void this(int i, float a)
you could call it with (int, int) and the int would convert.
If you have, in addition to the one above,
public static void this(float a, int i)
Now you can't call it with (int, int) as either would be a match.
Java defines widening and narrowing conversions, based on the
range (but not precision) of the types. Either assignment or method
call allow for widening without a cast, but require a cast for
narrowing. You can assign in int to a float without a cast, but
not a float to an int.
The method call rules are also used in the case of subclasses,
such that you can call a method expecting a reference to a superclass
of the class of the argument. That allows a subclass to only
overload the methods that change, allowing calls to the superclass
for ones that don't. Saves a lot of writing.
> Thus, for example, if you
> have a generic in some module, you find out about any potential problems
> when compiling the module; you don't have to check what you think are
> all possible ways to reference the generic, only to discover later that
> one of the users of your module used a way that you hadn't thought of.
> Your user will never see an error message about an ambiguous reference;
> you handle that beforehand. That's what I'm refering to when I say that
> it is a change in philosophy.
If they have to match, then you won't have the ambiguities that
Java recognizes in references at compile time.
> I'm not going to argue about which philosophy is "better". I just note
> that it would be a change. Changing a philosophical approach like that
> tends to be a bigger deal than adding a feature... and thus harder to
> sell.
I haven't gone through a detailed comparison, so I can't be sure
that it would work, but it might...
(snip of PL/I example)
Another note about PL/I and conversion. For PL/I ENTRY, if entry
points have different return types the return value is converted
to the type appropriate for the ENTRY point used. The compiler might
do enough flow analysis to know which ENTRY points can reach which
RETURN statement, but as far as I know it is usual to supply all
the possible conversions. A little different, and sometimes more
useful, than the EQUIVALENCE that Fortran does.
-- glen
glen herrmannsfeldt
(snip on VALUE arguments, and type conversion on calls)
>>So completely change the philosophy about how Fortran generic resolution
>>works? And do so just for the sake of this one feature? Good luck
>>selling that. :-) I'm sure it is "possible" to make such a thing work.
>>Selling it is another matter.
> It would have been fairly simple, actually, when VALUE was first
> perpetrated. I agree that it would have been totally different to
> the rest of Fortran's type handling in procedures, and not just in
> generic resolution.
(snip, I wrote)
>>> Note that PL/I allows passing arguments of different type, even
>>> without call by value. (A copy is passed, and you don't get the
>>> result back. Most often it is needed for constants.)
>>I won't get into a language war (as in, I won't reply further to this
>>aspect), but I always found that particular feature of PL/I to be a
>>pain. I'd make a mistake in referencing a procedure and instead of
>>giving me a compilation error, it would run and do... something.... but
>>nothing at all close to what I had in mind. ....
> As distinct from Perl, where that applies even to making syntax
> errors!
> More seriously, PL/I had many interesting features, but it was
> the archetypical committee camel, and it was nearly as hard to
> avoid tripping over its gotchas as it is in ISO C. If you want
> a language that got type conversion of procedure arguments right
> (though only for the built-in types), look at Algol 68.
Still my old favorite of PL/I is its ability to do conversion
between numeric and character (string) values on assignment.
In high school I wrote a program to print a square root table
using a DO loop with a CHAR variable. You have to do it
carefully, as it does a character string comparison, not a
numeric comparison. Something like:
DCL S CHAR(30);
DO S=' 1' TO ' 100' BY '1';
PUT SKIP LIST(S,SQRT(S));
END;
> If I were designing a language, one of the constructs would be
> specified type conversions, which would be applied automatically.
> And the compiler would check that they formed a DAG and there
> were no ambiguities, statically. It could be done, and would
> be efficient in all but lunatic cases.
> But I agree that starting from Fortran and going there would not
> be a journey that I would want to take!
-- glen
Phillip Helbig---undress to reply
<deeddd5e-9239-4c18...@em7g2000vbb.googlegroups.com>,
"Steven G. Johnson" <ste...@alum.mit.edu> writes:
> Normally Fortran's actual arguments have to be type compatible with
> the dummy argument (i.e. same type, for nonpolymorphic types). So you
> can't pass e.g. an INTEGER variable to a function expecting a REAL
> parameter. This makes a lot of sense for traditional Fortran pass-by-
> reference(-like) semantics.
>
> However, Fortran 2003 added a VALUE attribute, to allow passing
> arguments by value. NOTE 12.22 in the standard suggests that the
> intention was that "the effect is as if the actual argument is
> assigned to a temporary, and the temporary is then argument associated
> with the dummy argument."
Maybe I'm missing something here, but isn't the difference between
CALL SUB(X,Y)
and
CALL SUB((X),Y)
the fact that, effectively, in the second case X is being passed by
value? (The parentheses make it an expression, whose value is passed;
maybe in the implementation the result is stored read-only and a
reference to that is passed, but the effect is the same.)
Richard Maine
wrote:
> Maybe I'm missing something here, but isn't the difference between
>
> CALL SUB(X,Y)
>
> and
>
> CALL SUB((X),Y)
>
> the fact that, effectively, in the second case X is being passed by
> value? (The parentheses make it an expression, whose value is passed;
> maybe in the implementation the result is stored read-only and a
> reference to that is passed, but the effect is the same.)
Well, no. I would not say that it was passed by value from any of
multiple perspectives.
As you note, at an implementation level, it is more likely to look like
passing a copy by reference. For an actual pass by value, the caller and
the callee need to both agree that pass-by-value is happening. In this
case, the callee would not have any way of knowing that it has a call
like this. For example, I suggest not trying to use this to call a C
procedure that expects an argument by value.
At a higher level, sticking to things actually specified by the Fortran
standard, things are also different. Pass by value allows the callee to
modify the value of the dummy argument. The above construct does not.
While some implementations might not catch the error of modifying the
dummy argument value, it is still an error in the above form. With pass
by value, it is not an error. So from that perspective, no, I would not
say that the effect is the same.
nm...@cam.ac.uk
No. That's Algol 60-derived languages you are thinking of.
Expression arguments in Fortran share one of two characteristics
with them, but not the other.
If a variable occurring in an expression (including subscripts in
an array section) is changed in the call by some legal means, it
has no effect on the argument.
However, changing it is undefined behaviour, and a compiler is
perfectly entitled to pass X 'by reference' in both cases. This
differs from the VALUE attribute, which uses the same semantics
as in Algol 60 - i.e. it initialises a writable variable.
I have no idea whether that was introduced into Algol 60 by
oversight, but it was certainly trodden on in Algol 68.
I regret that Fortran has introduced it :-(
Regards,
Nick Maclaren.
robin
| glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
|
| > Note that PL/I allows passing arguments of different type, even
| > without call by value. (A copy is passed, and you don't get the
| > result back. Most often it is needed for constants.)
|
| I won't get into a language war (as in, I won't reply further to this
| aspect), but I always found that particular feature of PL/I to be a
| pain. I'd make a mistake in referencing a procedure and instead of
| giving me a compilation error, it would run and do... something.... but
| nothing at all close to what I had in mind. This typically happened to
| me in cases where the arguments were just completely FUBAR in ways that
| the compiler's conversion was not going to help. For example, I'd have
| the arguments in the wrong order or some such thing.
As Glen said, PL/I gives a warning message for such instances.
test: proc options (main);
declare x float;
call sub(x);
sub: procedure (k);
declare k fixed;
end sub;
end test;
C:\PLIFILES\DUMMY.pli(5:1) : IBM1214I W A dummy argument will be created
for argument number 1 in entry reference SUB.
Having the arguments in the wrong order is a clear programming error,
and you can't expect to get any message for that. The types of the swapped arguments
might be the same. If you are "lucky", you might accidentally get
a severe compilation error if by chance (for example) an array is passed to a scalar.
But whenever there is a type mismatch, you get some sort of message.
(Of course, the exception is for arguments that are constants or expressions.)
robin
| It would have been fairly simple, actually, when VALUE was first
| perpetrated. I agree that it would have been totally different to
| the rest of Fortran's type handling in procedures, and not just in
| generic resolution.
|
| I think that this whole area of Fortran, VALUE, argument passing
| and type handling in procedures, is a mistake. But there just
| wasn't any experience in 1958, and was almost none on generic
| procedures in 1977
In 1977, generic procedures had been in use for 11 years, at least,
in PL/I.
robin
CALL SUB((X), Y)
is used in PL/I to pass effectively by value, for it causes a dummy
to be created. It's a special case of an expression as an argument,
and in all such cases, a dummy is created.
robin
| Note that PL/I allows passing arguments of different type, even
| without call by value. (A copy is passed, and you don't get the
| result back. Most often it is needed for constants.)
In point of fact, a copy is not passed.
A dummy is created for such arguments.
The type of the dummy matches that of the corresponding
parameter [for Fortran, read "dummy argument"]. Thus, where types differ --
which is usually the case -- the dummy is not a copy.
nm...@cam.ac.uk
robin <rob...@dodo.mapson.com.au> wrote:
>
>| It would have been fairly simple, actually, when VALUE was first
>| perpetrated. I agree that it would have been totally different to
>| the rest of Fortran's type handling in procedures, and not just in
>| generic resolution.
>|
>| I think that this whole area of Fortran, VALUE, argument passing
>| and type handling in procedures, is a mistake. But there just
>| wasn't any experience in 1958, and was almost none on generic
>| procedures in 1977
>
>In 1977, generic procedures had been in use for 11 years, at least,
>in PL/I.
Sigh. Genericity, in the SIMPLE sense, is ancient; it has been
there in LISP and many assemblers since time immemorial. Algol 68
had it, too. That's irrelevant.
And, unfortunately, PL/I usage counts as "almost no experience",
largely because there was essentially NO experience with people
writing it TO A STANDARD and expecting their programs to port to
other systems with few, localised changes or simple global edits.
Heck, even within IBM, there wasn't even a single specification
of the PL/I language - it depended on which compiler you used!
Regards,
Nick Maclaren.
robin
| In article <4e04045f$0$57112$c30e...@exi-reader.telstra.net>,
| robin <rob...@dodo.mapson.com.au> wrote:
| >
| >| It would have been fairly simple, actually, when VALUE was first
| >| perpetrated. I agree that it would have been totally different to
| >| the rest of Fortran's type handling in procedures, and not just in
| >| generic resolution.
| >|
| >| I think that this whole area of Fortran, VALUE, argument passing
| >| and type handling in procedures, is a mistake. But there just
| >| wasn't any experience in 1958, and was almost none on generic
| >| procedures in 1977
| >
| >In 1977, generic procedures had been in use for 11 years, at least,
| >in PL/I.
|
| Sigh. Genericity, in the SIMPLE sense, is ancient; it has been
| there in LISP and many assemblers since time immemorial. Algol 68
| had it, too. That's irrelevant.
Genericity in assemblers is irrelevant.
You were talking about generic procedures, and so was I.
| And, unfortunately, PL/I usage counts as "almost no experience",
PL/I experience - introduced in 1966 - was considerable.
| largely because there was essentially NO experience with people
| writing it TO A STANDARD and expecting their programs to port to
| other systems with few, localised changes or simple global edits.
Initially, of course, IBM's was the standard, because it was the first
implementation. Other vendors produced compilers to that standard.
Later, an ANSI standard was published.
| Heck, even within IBM, there wasn't even a single specification
| of the PL/I language
IBM produced a single specification of the language.
| - it depended on which compiler you used!
No it didn't. Their subset compiler (D) was precisely that, a subset.
The subset was upwards compatible with the F compiler.
| Regards,
| Nick Maclaren.