|
|
 |
 |
 |
 |
Fortran Programming Language
|
 |
 |
 |
 |
|
|
|
|
overloaded cant be distinguished by return values?
I am trying to distinguisch overloaded functions by their result value
but get an error message from ifort 9.1:
>cat overload.f90 ; ifort overload.f90 -c
module a
interface test
module procedure testa, testb
end interface test
contains
function testa() result(a)
integer :: a
a = 1
end function testa
function testb() result(b)
character(len=8) :: b
b = 'result'
end function testb
end module a
fortcom: Warning: overload.f90, line 14: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [TESTB]
function testb() result(b)
-----------^
Is this correct behaviour or an error of ifort. pgf90/pgf95 version
7.0 does compile this example.
Kind regards
Berthold Hllmann
--
__ Address:
G / \ L Germanischer Lloyd
phone: +49-40-36149-7374 -+----+- Vorsetzen 35 P.O.Box 111606
fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg
"Berthold "Hllmann"" <berth @despammed.com> wrote in message
> I am trying to distinguisch overloaded functions by their result value
> but get an error message from ifort 9.1:
their arguments ("Fortran 95/2003 Explained", Section 5.18).
Regards,
Mike Metcalf
Michael Metcalf wrote: > "Berthold "Hllmann"" <berth @despammed.com> wrote in message > news:seodk2la4b.fsf@pc047299.dhcp.germanlloyd.org... >> I am trying to distinguisch overloaded functions by their result value >> but get an error message from ifort 9.1: > The message is correct. Overloaded procedures are disambiguated according to
> their arguments ("Fortran 95/2003 Explained", Section 5.18).
> Regards,
example of the rule in Fortran that the RHS of any expression is
evaluated before the LHS is considered. This is why
REAL :: a
a = 1/2
results in a being set equal to zero.
Richard
On May 30, 9:17 am, Richard Edgar <r@pas.rochester.edu> wrote:
> Michael Metcalf wrote: > > "Berthold "Hllmann"" <berth @despammed.com> wrote in message > > news:seodk2la4b.fsf@pc047299.dhcp.germanlloyd.org... > >> I am trying to distinguisch overloaded functions by their result value > >> but get an error message from ifort 9.1: > > The message is correct. Overloaded procedures are disambiguated according to
> > their arguments ("Fortran 95/2003 Explained", Section 5.18).
> > Regards,
> Being more general (please correct me if I'm wrong...), this is an
> example of the rule in Fortran that the RHS of any expression is
> evaluated before the LHS is considered. This is why
> REAL :: a
> a = 1/2
> results in a being set equal to zero.
me that there is anything on the left hand side to be "evaluated". It
simply says "set variable (a) equal to something" (that must be
evaluated). I wouldn't necessarily expect it to look at the left hand
side to determine whether the variable is real or integer before
deciding how to evaluate the RHS. It would appear that Fortran does
what I would consider to be the "natural thing".
Richard Edgar wrote: > Being more general (please correct me if I'm wrong...), this is an
> example of the rule in Fortran that the RHS of any expression is
> evaluated before the LHS is considered.
result not being a dummy argument, although in some respects it may
behave similar to one with intent(out). In particular, the function
result object is short lived in that it ceases being defined once the
assignment to the LHS at call is performed.
Regards
Reinhold Bader wrote:
> Richard Edgar wrote:
>>Being more general (please correct me if I'm wrong...), this is an
>>example of the rule in Fortran that the RHS of any expression is
>>evaluated before the LHS is considered.
> If I've understood it correctly, it is simply a case of a function
> result not being a dummy argument, although in some respects it may
> behave similar to one with intent(out). In particular, the function
> result object is short lived in that it ceases being defined once the
> assignment to the LHS at call is performed.
The function result is converted to the type needed in the expression
where the function is called. It is a one way path from the function
result type to the expression and not the other way around.
In some cases the function call is implemented by passing an additional
argument to the function, such that the return value is stored in
that argument. The passed argument corresponds to the known function
return type, not the other way around.
It might be possible to define a language that did function
calls differently, but that is not Fortran nor any of the other
popular languages. There are many cases where the function
return type is not known in the way needed to resolve
generic function calls.
-- glen
Berthold Hllmann wrote:
...
> module a > interface test
> module procedure testa, testb
> end interface test
> contains
> function testa() result(a)
> integer :: a
> a = 1
> end function testa
> function testb() result(b)
> character(len=8) :: b
> b = 'result'
> end function testb
> end module a
call:
Write(*,*) test()
Which of the instances of test should be called here?
There are some languages (like Ada, for example) where the
overloading of a generic can be determined by the result type
because there are no contexts in the language where a reference
may be written such that the required type isn't known from that
context. There's even a formal name for type mechanisms
designed that way (which I always disremember).
Fortran doesn't have that property. The type of anything in
Fortran is determined by its own appearance (like a literal),
its own declaration (like most variables and non-generic
functions), or based on the types of its operands (like operator
results or generic function references).
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
glen herrmannsfeldt <g @ugcs.caltech.edu> wrote: > Reinhold Bader wrote: > > Richard Edgar wrote:
> >>Being more general (please correct me if I'm wrong...), this is an
> >>example of the rule in Fortran that the RHS of any expression is
> >>evaluated before the LHS is considered.
> > If I've understood it correctly, it is simply a case of a function
> > result not being a dummy argument, although in some respects it may
> > behave similar to one with intent(out). In particular, the function
> > result object is short lived in that it ceases being defined once the
> > assignment to the LHS at call is performed.
(or anything else) that it is associated with, and thus nothing to
disambiguate based on.
> The function result is converted to the type needed in the expression
> where the function is called.
function result is whatever type (and type parameters) it is. Period.
There is no automatic conversion that relates in any way to it being a
function.
The closest things I can think of that you might be referring to are the
conversions done by some intrinsic operators and by some intrinsic
assignments. However, these conversions have nothing to do with whether
or not the datum to be converted is a function result. They are also a
very specific and limitted set of conversions. There is no general rule
that anything (function result or otherwise) is converted to the needed
type.
I'm moderately sure that you (Glen) know this. I thus suspect that you
meant to say something other than what the above actually says. Either
that or perhaps you were confusing languages. I'm not sure exactly what
was intended, and I guess it doesn't much matter. Mostly, I wanted to
correct the statement so that someone else didn't read it and think that
it was correct as it stands.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Richard Maine wrote:
(snip, I wrote)
>>The function result is converted to the type needed in the expression
>>where the function is called.
> No. That is not so. There is no rule even vaguely like that. The
> function result is whatever type (and type parameters) it is. Period.
> There is no automatic conversion that relates in any way to it being a
> function.
I meant the conversion that happen to any quantity in an expression,
and, yes, not related to its being a function.
> The closest things I can think of that you might be referring to are the
> conversions done by some intrinsic operators and by some intrinsic
> assignments. However, these conversions have nothing to do with whether
> or not the datum to be converted is a function result. They are also a
> very specific and limitted set of conversions. There is no general rule
> that anything (function result or otherwise) is converted to the needed
> type.
If I have, for example,
INTEGER XYZ
COMPLEX Z
Z=2.E0+XYZ(123)
the INTEGER result from the function is converted to REAL,
added to 2.E0, then then the sum is converted to COMPLEX.
> I'm moderately sure that you (Glen) know this. I thus suspect that you
> meant to say something other than what the above actually says. Either
> that or perhaps you were confusing languages. I'm not sure exactly what
> was intended, and I guess it doesn't much matter. Mostly, I wanted to
> correct the statement so that someone else didn't read it and think that
> it was correct as it stands.
What statement would you use to describe the conversion of the
function result to REAL?
-- glen
glen herrmannsfeldt <g @ugcs.caltech.edu> wrote: > Richard Maine wrote: > > The closest things I can think of that you might be referring to are the > > conversions done by some intrinsic operators and by some intrinsic > > assignments. ... They are also a > > very specific and limitted set of conversions. There is no general rule > > that anything (function result or otherwise) is converted to the needed > > type. > If I have, for example,
> INTEGER XYZ
> COMPLEX Z
> Z=2.E0+XYZ(123)
> the INTEGER result from the function is converted to REAL,
> added to 2.E0, then then the sum is converted to COMPLEX.
does not generalize. If you have
real_variable + function_that_returns a logical(something)
then there won't be any conversion, for example.
> What statement would you use to describe the conversion of the
> function result to REAL?
I wouldn't. I wouldn't describe it from that persp[ective at all. I
would say (as the standard does), that what you are talking about is a
property of the intrinsic addition operation - that that particular
operation allows the addition of a real and an integer, which gives a
real result.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
|
|
|
|
|
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc