Home > Archive > Fortran > September 2006 > How can I simply use (old) routines?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How can I simply use (old) routines?
|
|
|
| Hi all,
I have a bunch of old routines, written by others, that I would like to
use in my code. However, it seems that I cannot access those routines
if I have an 'implicit none' in my program.
For example, the following does not compile:
** set_number.f90 **
integer function set_number(i)
implicit none
integer,intent(in) :: i
set_number = 2*i
end function set_number
**********************************
** main.f90 **
program test
implicit none
integer :: i,j
i = 1
j = set_number(i)
write(*,*) j
end program test
**********************************
g95 set_number.f90 main.f90
results in:
Error: Function 'set_number' at (1) has no implicit type
The intel compiler gives a similar error.
What is the problem here? Why does this not work?
I know two ways to solve it; make use of modules, or add a line
'integer :: set_number' in main.f90, but I just would like to know why
the code given above doesn't work.
Thanks!
Arno
| |
| michael@athenavisual.com 2006-09-18, 7:01 pm |
| Just add the statement
integer:: set_number
in your main program and it will work fine.
Cheers
Michael
Arno wrote:
> Hi all,
>
> I have a bunch of old routines, written by others, that I would like to
> use in my code. However, it seems that I cannot access those routines
> if I have an 'implicit none' in my program.
>
> For example, the following does not compile:
>
> ** set_number.f90 **
>
> integer function set_number(i)
>
> implicit none
> integer,intent(in) :: i
>
> set_number = 2*i
>
> end function set_number
>
> **********************************
> ** main.f90 **
>
> program test
>
> implicit none
> integer :: i,j
>
> i = 1
> j = set_number(i)
> write(*,*) j
>
> end program test
>
> **********************************
>
> g95 set_number.f90 main.f90
> results in:
> Error: Function 'set_number' at (1) has no implicit type
>
> The intel compiler gives a similar error.
>
> What is the problem here? Why does this not work?
>
> I know two ways to solve it; make use of modules, or add a line
> 'integer :: set_number' in main.f90, but I just would like to know why
> the code given above doesn't work.
>
> Thanks!
>
> Arno
| |
| Jan Vorbrüggen 2006-09-18, 7:01 pm |
| Well, what did you expect? The "IMPLICIT NONE" tells the compiler that you
want - and need - to declare the type of all variables yourself. In this case,
the return value of the function you want to call similarly needs such a
declaration - and you correctly specified it at the end of the post. So
where's the problem - do you expect the compiler to read your mind, perhaps?
Jan
| |
| claude.simon@equipement.gouv.fr 2006-09-18, 7:01 pm |
|
Arno a =E9crit :
> Hi all,
>
> I have a bunch of old routines, written by others, that I would like to
> use in my code. However, it seems that I cannot access those routines
> if I have an 'implicit none' in my program.
>
> For example, the following does not compile:
>
> ** set_number.f90 **
>
> integer function set_number(i)
>
> implicit none
> integer,intent(in) :: i
>
> set_number =3D 2*i
>
> end function set_number
>
> **********************************
> ** main.f90 **
>
> program test
>
> implicit none
> integer :: i,j
>
> i =3D 1
> j =3D set_number(i)
> write(*,*) j
>
> end program test
>
> **********************************
>
in the program test you said (implicit none) that you want all things
must have a type declared and you omit to declare the type of the
function set_number.
It is what g95 is saying
> g95 set_number.f90 main.f90
> results in:
> Error: Function 'set_number' at (1) has no implicit type
>
> The intel compiler gives a similar error.
>
> What is the problem here? Why does this not work?
>
> I know two ways to solve it; make use of modules, or add a line
> 'integer :: set_number' in main.f90, but I just would like to know why
> the code given above doesn't work.
>=20
> Thanks!
>=20
> Arno
| |
|
| But the compiler does know what the return value of the function is, as
the function is said to be an integer function:
integer function set_number(i)
So, why do I have to specify that again in main.f90?
Arno
Jan Vorbr=FCggen wrote:
> Well, what did you expect? The "IMPLICIT NONE" tells the compiler that you
> want - and need - to declare the type of all variables yourself. In this =
case,
> the return value of the function you want to call similarly needs such a
> declaration - and you correctly specified it at the end of the post. So
> where's the problem - do you expect the compiler to read your mind, perha=
ps?
>=20
> Jan
| |
| Richard Maine 2006-09-18, 7:01 pm |
| Arno <arnoinperu@hotmail.com> wrote:
> But the compiler does know what the return value of the function is, as
> the function is said to be an integer function:
> integer function set_number(i)
>
> So, why do I have to specify that again in main.f90?
No the compiler does not know that *WHEN COMPILING THE MAIN PROGRAM". It
is fundamental to the design external procedures that they can be
compiled separately. Your function could, in principle, be in a separate
file - one that you haven't even written yet when compiling the main
program. So the compiler doesn't get to "look" at the function when
compiling the main. The standard is written from that viewpoint.
Internal and modul functions, introduced in f90, are different. In those
cases, the compiler does know about the function when compiling the
main. If you think that is a better way for things to be, I agree; I
recommend using module or internal procedures instead of external ones
in most cases. But external procedures were the only option before f90,
so if you have old code and don't want to change it, then you have to
play by the rules for external procedures.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| michael@athenavisual.com 2006-09-18, 7:01 pm |
| Program test
Use toto
Integer:: i,j
i=1
j=set_number(i)
Print *,i,j
End
Module toto
Interface
Integer Function set_number(i)
Implicit None
Integer,Intent(in) :: i
End Function set_number
End Interface
End Module
Integer Function set_number(i)
Implicit None
Integer,Intent(in) :: i
set_number = 2*i
End Function set_number
Arno wrote:
> Hi all,
>
> I have a bunch of old routines, written by others, that I would like to
> use in my code. However, it seems that I cannot access those routines
> if I have an 'implicit none' in my program.
>
> For example, the following does not compile:
>
> ** set_number.f90 **
>
> integer function set_number(i)
>
> implicit none
> integer,intent(in) :: i
>
> set_number = 2*i
>
> end function set_number
>
> **********************************
> ** main.f90 **
>
> program test
>
> implicit none
> integer :: i,j
>
> i = 1
> j = set_number(i)
> write(*,*) j
>
> end program test
>
> **********************************
>
> g95 set_number.f90 main.f90
> results in:
> Error: Function 'set_number' at (1) has no implicit type
>
> The intel compiler gives a similar error.
>
> What is the problem here? Why does this not work?
>
> I know two ways to solve it; make use of modules, or add a line
> 'integer :: set_number' in main.f90, but I just would like to know why
> the code given above doesn't work.
>
> Thanks!
>
> Arno
| |
| Ron Shepard 2006-09-18, 7:01 pm |
| In article <1158594066.586152.289640@d34g2000cwd.googlegroups.com>,
"Arno" <arnoinperu@hotmail.com> wrote:
> But the compiler does know what the return value of the function is, as
> the function is said to be an integer function:
> integer function set_number(i)
>
> So, why do I have to specify that again in main.f90?
Imagine (or actually do this) putting the function in one file and
the main program in another file. Now when you ask that question,
it is clear why the main program must declare the function type for
the external function. Fortran is designed to allow separate
compilation of external functions (maybe they are written in another
language, or perhaps you have only the object code to link, so the
compiler could never see the function source code in these cases
anyway) so even if the source code is in the same file, that is
irrelevant to the declaration rules in the various separate
subprograms.
Having said this, some fortran compilers do look within a file for
interface checking and optimization, but the language standard does
not require this, and it does not eliminate the need to declare
variables and function return types either explicitly or implicitly.
$.02 -Ron Shepard
| |
| e p chandler 2006-09-18, 7:01 pm |
|
Arno wrote:
> Hi all,
>
> I have a bunch of old routines, written by others, that I would like to
> use in my code. However, it seems that I cannot access those routines
> if I have an 'implicit none' in my program.
>
> For example, the following does not compile:
>
> ** set_number.f90 **
>
> integer function set_number(i)
>
> implicit none
> integer,intent(in) :: i
>
> set_number = 2*i
>
> end function set_number
>
> **********************************
> ** main.f90 **
>
> program test
>
> implicit none
> integer :: i,j
>
> i = 1
> j = set_number(i)
> write(*,*) j
>
> end program test
>
> **********************************
>
> g95 set_number.f90 main.f90
> results in:
> Error: Function 'set_number' at (1) has no implicit type
>
> The intel compiler gives a similar error.
>
> What is the problem here? Why does this not work?
>
> I know two ways to solve it; make use of modules, or add a line
> 'integer :: set_number' in main.f90, but I just would like to know why
> the code given above doesn't work.
>
> Thanks!
>
> Arno
Remember too that F90+ makes it much easier to detect argument
mis-matches between caller and called routines. This is a major source
of bugs along with un-initialized/un-declared variables and violating
array bounds.
-- e-mail: epc8 at juno dot com
| |
| David Frank 2006-09-18, 7:01 pm |
| Others have told you what the problem is, however
its my understanding that Lahey.f90 will GATHER these interfaces
for you if the "external" routine is in the same file as the program file.
I always thought that was a NEAT feature that other compilers shud adopt.
| |
| Ben Hetland 2006-09-18, 7:01 pm |
| Jan Vorbrüggen wrote:
> Well, what did you expect? The "IMPLICIT NONE" tells the compiler that you
> want - and need - to declare the type of all variables yourself. In this
> case, the return value of the function you want to call similarly needs
> such a declaration
Actually it seems to mean that you need to declare the type and name of
all variables and functions, but not subroutines nor parameters to
functions or subroutines.
Without taking the step of moving all these into a module, I'd prefer to
declare the function in a separate include file that I could 'include'
in whichever other place I wanted to use the routines/functions.
Retyping them explicitly in each subroutine of function is too error
prone and gives a maintenance problem if one chooses to change the
return type of a function later on.
--
-+-Ben-+-
| |
| glen herrmannsfeldt 2006-09-18, 7:01 pm |
| Arno <arnoinperu@hotmail.com> wrote:
> I have a bunch of old routines, written by others, that I would like to
> use in my code. However, it seems that I cannot access those routines
> if I have an 'implicit none' in my program.
(snip, including the definition of an INTEGER function set_number)
> program test
> implicit none
> integer :: i,j
> i = 1
> j = set_number(i)
> write(*,*) j
> end program test
> g95 set_number.f90 main.f90
> results in:
> Error: Function 'set_number' at (1) has no implicit type
IMPLICIT NONE or not, this should not work. Without a
declaration for set_number in main, it will implicitely
be real.
This is exactly the reason you want IMPLICIT NONE to catch
these errors.
If this worked without the IMPLICIT NONE you were very lucky.
-- glen
| |
| glen herrmannsfeldt 2006-09-18, 7:01 pm |
| Arno <arnoinperu@hotmail.com> wrote:
> But the compiler does know what the return value of the function is, as
> the function is said to be an integer function:
> integer function set_number(i)
Fortran has no memory of what happens in another function or subroutine.
(This is unlike C, which has file scope variables and declarations.)
I remember watching many beginning Fortran programmers dimension
arrays in the main program, but not in a Function, assuming that
the compiler would remember them. The result, as it turns out,
is not a compilation error but at run time instead of referencing
the array data executes it as executable code, instead.
(That was Fortran 66, but I believe current standards still do the
same thing.)
It is common in writing a Fortran compiler, at the end of compiling
one function or subroutine to reinitialize everything, except possibly
the I/O system reading the source file.
-- glen
| |
| glen herrmannsfeldt 2006-09-18, 7:01 pm |
| David Frank <dave_frank@hotmail.com> wrote:
> Others have told you what the problem is, however
> its my understanding that Lahey.f90 will GATHER these interfaces
> for you if the "external" routine is in the same file as the program file.
> I always thought that was a NEAT feature that other compilers shud adopt.
That is fine, but it is not Fortran. Such a compiler would seem to
be non-standard, and should not do that if any flags specifying no
extensions to the standard are on.
-- glen
| |
| Richard Maine 2006-09-18, 7:01 pm |
| Ben Hetland <ben.a.hetland@sintef.no> wrote:
> Jan Vorbrüggen wrote:
>
> Actually it seems to mean that you need to declare the type and name of
> all variables and functions, but not subroutines nor parameters to
> functions or subroutines.
Actually, actually, :-) it means that you need to declare the type of
every named entity that has a type. That includes named variables, named
constants (aka parameters), and functions. Subroutines don't have a
type.
I'm slightly  what you mean about "parameters to subroutines or
functions". I do understand that you presumably mean arguments instead
of parameters. (One should avoid using the word "parameter" to refer to
a procedure argument in Fortran, or you'll get with the Fortran
parameter statement. No, I don't like the confusion, but it came in with
f77 and we are pretty much stuck with it now. Subroutines have
arguments; parameters are named constants.) Anyway...
Yes, you do need to declare the types of dummy arguments; they are
variables. My best guess is that you are talking about the fact that you
don't have to have explicit interfaces just because you have implicit
none. There are people (myself included) who would like a way to specify
that implicit interfaces are disallowed; anyway the concept makes sense.
But if that's what you mean, I would not say that it is accurate to
describe it in terms of needing to declare the types of arguments.
Indeed, if you have an explicit interface with implicit none, you do
have to declare the types of the dummy arguments. Hmm. You might be
referring to the (unfortunate, IMO) fact that implicit none does not
host associate into interface bodies. Well, too much speculation on my
part.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Craig Powers 2006-09-18, 7:01 pm |
| glen herrmannsfeldt wrote:
> David Frank <dave_frank@hotmail.com> wrote:
>
> That is fine, but it is not Fortran. Such a compiler would seem to
> be non-standard, and should not do that if any flags specifying no
> extensions to the standard are on.
It depends... it would be nonstandard, e.g., if it automagically picked
up interfaces or types that would otherwise have to be specified
explicitly. On the other hand, it could also catch argument mismatches
that are not allowed (er, I presume they're not allowed), but not
required to be detected, which would be a good thing (although probably
not prevalent outside of toy problems unless the feature is really
ambitious and works across separate files).
| |
| glen herrmannsfeldt 2006-09-18, 7:01 pm |
| Craig Powers <enigma@hal-pc.org> wrote:
(snip on compilers remembering type information between subprograms)
> It depends... it would be nonstandard, e.g., if it automagically picked
> up interfaces or types that would otherwise have to be specified
> explicitly. On the other hand, it could also catch argument mismatches
> that are not allowed (er, I presume they're not allowed), but not
> required to be detected, which would be a good thing (although probably
> not prevalent outside of toy problems unless the feature is really
> ambitious and works across separate files).
Warnings on argument type mismatch could be useful. As far as I know,
Fortran isn't allowed to do type conversion of arguments like C and
PL/I (and probably others) do. I believe there are linkers that
can do it across files, and probably also for the return type of
but as a warning or error, not to do automatic conversion.
-- glen
| |
| Richard Maine 2006-09-18, 7:01 pm |
| glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
> As far as I know, Fortran isn't allowed to do type conversion of arguments...
One needs to phrase it more precisely than "Fortran isn't allowed" in
order to get a correct answer because the answer differs depending on
exactly what you mean by that phrase.
1. A Fortran program is not allowed to have such type disagreements.
Thus if "Fortran isn't allowed" means that a standard-conforming Fortran
program isn't allowed, then that is correct.
2. However, a Fortran compiler is allowed to do such things. It only
comes up for programs that are non-conformant. A compiler is allowed to
do anything with such programs, this not being one of the things that
triggers a mandatory diagnosis in the standard. In particular, a
compiler is allowed to "fix up" the error by doing type conversion. I
would consider that an annoying feature of a compiler, and I don't know
of any that intentionally do it (I discount disagreements that just
happen to work by accident; there exist some cases of that). But if
"Fortran isn't allowed" means that a standard-conforming Fortran
compiler isn't allowed, then that is wrong; the standard has no
prohibition against a compiler doing that.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| glen herrmannsfeldt 2006-09-18, 7:01 pm |
| Richard Maine <nospam@see.signature> wrote:
> glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
[color=darkred]
> One needs to phrase it more precisely than "Fortran isn't allowed" in
> order to get a correct answer because the answer differs depending on
> exactly what you mean by that phrase.
> 1. A Fortran program is not allowed to have such type disagreements.
> Thus if "Fortran isn't allowed" means that a standard-conforming Fortran
> program isn't allowed, then that is correct.
Maybe I read/posted on comp.lang.c too much, though I haven't for
a long time. In comp.lang.c it is implied that all discussions
regard what the standard says, and what standard conforming programs
expect. I believe this is the one I meant.
> 2. However, a Fortran compiler is allowed to do such things. It only
> comes up for programs that are non-conformant. A compiler is allowed to
> do anything with such programs, this not being one of the things that
> triggers a mandatory diagnosis in the standard. In particular, a
> compiler is allowed to "fix up" the error by doing type conversion. I
> would consider that an annoying feature of a compiler, and I don't know
> of any that intentionally do it
C, with call by value, can do it fairly easily. Because of the
large variety of types in PL/I, it is a useful feature, especially
for constants. It is done by passing a temporary, so no value is
returned.
> (I discount disagreements that just
> happen to work by accident; there exist some cases of that).
I have seen this called an advantage for little endian representation.
I consider it a di vantage in that it can hide bugs such that they
show up at an inopportune time.
> But if
> "Fortran isn't allowed" means that a standard-conforming Fortran
> compiler isn't allowed, then that is wrong; the standard has no
> prohibition against a compiler doing that.
OK, I agree with this one, especially for constants.
-- glen
| |
| Richard Maine 2006-09-18, 7:01 pm |
| glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
> Maybe I read/posted on comp.lang.c too much, though I haven't for
> a long time. In comp.lang.c it is implied that all discussions
> regard what the standard says, and what standard conforming programs
> expect. I believe this is the one I meant.
That's most often the case here also, but we do also get questions about
what compilers are allowed to do. Specifically, we fairly often get
questions about why some piece of invalid code didn't give an error
message, sometimes from people who fail to appreciate that just because
a program is nonconforming, that doesn't mean that a compiler is
nonconforming for failing to diagnose it.
The standard has both requirements of programs and requirements on
compilers (ok, processors). Although they are related, you cannot
completely deduce one from the other. You actually do have to
distinguish (and the standard tries to be careful about doing so, though
I think there have been cases where it messed up). There exist cases
where a statement in the standard could mean two completely different
things, depending on whether it is read as a requirement on the compiler
or on the program, and both readings could make sense.
I said:
>
> I have seen this called an advantage for little endian representation.
> I consider it a divantage in that it can hide bugs such that they
> show up at an inopportune time.
Yes, that was one of the particular cases I had in mind. I've seen code
that took advantage of this. I've had to port such code (yukk). And I've
talked to users who thought that this was an intentional conversion done
by the compiler, not realizing that the compiler didn't need to do any
such conversion, but that it just happened to work.
I agree with your evaluation of the "feature" as a divantage.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
|
| Thanks to you all. I do not only know how to deal with it, but also
why!
Arno
| |
| Ben Hetland 2006-09-19, 7:02 pm |
| Richard Maine wrote:
> Actually, actually, :-) it means that you need to declare the type of
> every named entity that has a type. That includes named variables, named
> constants (aka parameters), and functions. Subroutines don't have a
> type.
Well, sorry about that! Whether we call things arguments or parameters,
parameters or constants, dummy arguments or formal parameters, I'll try
to remember to call them according to the "Fortran terminology", since
that is after all what we are discussing ... As you say; anyway ... :-)
Whether or not subroutines do have a "type" depends on which way you
look at it. Subroutines and functions may not be described only in terms
of what they (possibly) /return/. An important property of both of them
is also which para^H^H^H^H arguments they need and the type expected for
each argument. This is important not only to the function/subroutine
itself, it is also of importance to the calling routines in order to set
up the call correctly. The way one looks at it in for instance ANSI C
and C++ is therefore to regard all this information as its "type". For
it is the simplest way to enable the compiler to detect and report
erroneous usage. If you actually say IMPLICIT NONE, I'd say that chances
are high that you wouldn't want this kind of information to be implicit
either ... (Otherwise one might have wanted to say IMPLICIT SOME?)
The additional information about the type can also be used to
distinguish between functions/subroutines with the same name but
different argument list, as is for example done with function
overloading in C++. Fortran too can do overloading to some extent, at
least for operators (which are in essence just functions), and with that
the choice of correct argument types become crucial to the correct
choice of which function to call.
Enter the INTERFACE statements in Fortran, I guess. :-)
> Yes, you do need to declare the types of dummy arguments; they are
> variables.
They are variables primarily in the context of the routine's own body.
Outside of that context, as in the caller routine, they may not always
be variables. For instance a constant ("parameter") or a literal value
could be used. Or even a temporary (value/variable) returned from
another function. (In spite of this I observe that most Fortran
programmers with a bit of experience prefer to put each argument [to be]
into a local variable first, then send the variables as arguments in the
function or subroutine call.)
> My best guess is that you are talking about the fact that you
> don't have to have explicit interfaces just because you have implicit
> none. There are people (myself included) who would like a way to specify
> that implicit interfaces are disallowed; anyway the concept makes sense.
Good guess! ;-)
--
-+-Ben-+-
| |
| Jan Vorbrüggen 2006-09-19, 7:02 pm |
| > Enter the INTERFACE statements in Fortran, I guess. :-)
No, INTERFACE is a measure of last resort. First, try MODULEs and/or
CONTAINed procedures. Then, try MODULEs... Then, try MODULEs... Finally,
make sure you really can't use a MODULE, and only then write an INTERFACE.
The usual C/C++ .h files with interface declarations have the property that
you can include them in the actual implementation, and the compiler will check
that the implementation matches the interface declaration. Unfortunately, the
writers of the F90 standard disallowed this. Yes, the situations where one is
forced to use INTERFACE are such that this operation wouldn't be possible.
Nonetheless, just prohibiting it didn't and doesn't make any sense, IMO.
Jan
| |
| Richard E Maine 2006-09-19, 7:02 pm |
| Ben Hetland <ben.a.hetland@sintef.no> wrote:
> Whether or not subroutines do have a "type" depends on which way you
> look at it.
Yes, I know. And I'd personally like to be able to look at them as
having a type in some sense, even if the type that they had was "no
type", perhaps roughly comparable to C void. It would sure simplify the
wording in several places, for example, if we could just say that "the
types have to agree" instead of adding long treatises explaining that
the types have to agree in the cases where there are types, or both
things have to be subroutines, etc.
However, the Fortran standard distinctly does not look at subroutines as
having a type; it does do the long-winded version instead. In 99% (a
number I just made up, of course) of the cases, you can think of
subroutines as having a special type of "no type", remember simplified
versions of the rules, and you'll get the same answer anyway. But if you
are doing fine points of interpretation of tricky cases (usually cases
of things that I would never code myself), you need to use the
standard's definition/viewpoint instead of some more-or-less equivalent
one; otherwise, the "less" part of the "mode-or-less" bites you.
> Enter the INTERFACE statements in Fortran, I guess. :-)
Let me second Jan's reply. "Just say no" to interface bodies in most
cases.
>
> They are variables primarily in the context of the routine's own body.
> Outside of that context, as in the caller routine, they may not always
> be variables.
You are confusing dummy arguments and actual arguments. They are not the
same thing at all; really. They aren't even close to the same kind of
thing. Yes, it matters - a lot. So much that it is hard to talk
coherently about them without making the distinction.
In particular, talking about declaring the type of an actual argument
makes no more sense than (and would be very comparable to - the example
is not at all contrived) declaring the type of the right-hand-size of an
assignment statement. Yes, you can declare the type of variables (and
other entities) that appear in the right-hand-size (or in an actual
argument). But even if the right-hand-size (or actual argument) consists
of a single variable, what you are declaring is the type of that
variable - not the type of the right-hand-size (or actual argument).
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| robin 2006-09-19, 10:01 pm |
| Arno wrote in message <1158592972.119755.310100@i42g2000cwa.googlegroups.com>...
>Hi all,
>
>I have a bunch of old routines, written by others, that I would like to
>use in my code. However, it seems that I cannot access those routines
>if I have an 'implicit none' in my program.
>
>For example, the following does not compile:
>
>** set_number.f90 **
>
>integer function set_number(i)
>
>implicit none
>integer,intent(in) :: i
>
>set_number = 2*i
>
>end function set_number
>
>**********************************
>** main.f90 **
>
>program test
>
>implicit none
>integer :: i,j
>
>i = 1
>j = set_number(i)
>write(*,*) j
>
>end program test
>
>**********************************
>
>g95 set_number.f90 main.f90
>results in:
>Error: Function 'set_number' at (1) has no implicit type
>
>The intel compiler gives a similar error.
>
>What is the problem here? Why does this not work?
It's because SET_NUMBER has not been given a type,
as the error message says.
>I know two ways to solve it; make use of modules, or add a line
>'integer :: set_number' in main.f90, but I just would like to know why
>the code given above doesn't work.
It has told you.
In the main program, you need to give SET_NUMBER a type,
because the main program does not know what the type of SET_NUMBER is..
A third way to resolve the matter is as follows:
program test
implicit none
integer :: i,j
i = 1
j = set_number(i)
write(*,*) j
contains
integer function set_number(i)
implicit none
integer,intent(in) :: i
set_number = 2*i
end function set_number
end program test
>Thanks!
>
>Arno
| |
| Ben Hetland 2006-09-20, 8:01 am |
| NNTP-Posting-Host: 129.241.234.101
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: orkan.itea.ntnu.no 1158751119 26992 129.241.234.101 (20 Sep 2006 11:18:39 GMT)
X-Complaints-To: usenet@itea.ntnu.no
NNTP-Posting-Date: Wed, 20 Sep 2006 11:18:39 +0000 (UTC)
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
In-Reply-To: <1hlwkzl.1wddxkg86r6c4N%nospam@see.signature>
X-Enigmail-Version: 0.94.0.0
Xref: number1.nntp.dca.giganews.com comp.lang.fortran:151637
Richard E Maine wrote:
>
>
> Let me second Jan's reply. "Just say no" to interface bodies in most
> cases.
OK, I have no problem with listening to what the experts in the language
has to say about this. I was actually just trying to understand myself
why its introduction had once been considered justified.
>
> You are confusing dummy arguments and actual arguments. They are not the
> same thing at all; really. They aren't even close to the same kind of
> thing. Yes, it matters - a lot. So much that it is hard to talk
> coherently about them without making the distinction.
Either I or you are confusing them, but I've got a feeling we're just
misunderstanding each other. I was referring to the dummy arguments as
the "named things" one writes when one writes the SUBROUTINE or FUNCTION
content. And they are declared like variables are (hmm.. at least with
IMPLICIT NONE).
> In particular, talking about declaring the type of an actual argument
> makes no more sense than (and would be very comparable to - the example
> is not at all contrived) declaring the type of the right-hand-size of an
> assignment statement.
I didn't say that! Or at least didn't intend to, as I see in hindsight
that my poor paragraph about this was "asking" for a misinterpretation
.... :-(
Anyway, what I tried to say was that the "expression" one uses as an
actual argument did have an implied type, or rather the result of that
expression to be precise. No it isn't declared in any way, but if one
writes for instance the expression (2+I) then the result from that
calculation would have an implicit type accociated with it (here most
likely INTEGER).
If you put this expression in an argument list when calling a
subroutine, then that result would be associated with the corresponding
dummy variable (as seen if you for example single-step a debugger into
the subroutine). The type of the expression should match the (declared)
type of the dummy argument, or at least be compatible in some
deterministic way. If not you're begging for run-time problems! To
relate this with OP's problem, the point would be to help the compiler
to verify that the dummy and the actual argument matches in type.
--
-+-Ben-+-
| |
| Craig Powers 2006-09-20, 7:01 pm |
| Ben Hetland wrote:
> I was referring to the dummy arguments as
> the "named things" one writes when one writes the SUBROUTINE or FUNCTION
> content. And they are declared like variables are (hmm.. at least with
> IMPLICIT NONE).
<rules lawyer>
No, they're not *declared* like variables are. Dummy arguments are
declared in the argument list. Variables are (sort of, in most cases)
declared in one of the specification statements that can also be used to
provide type and other attributes to dummy arguments (or, in the case of
no IMPLICIT NONE, they are declared at first use).
</rules lawyer>
| |
| Richard E Maine 2006-09-20, 7:01 pm |
| Craig Powers <enigma@hal-pc.org> wrote:
> Ben Hetland wrote:
>
> <rules lawyer>
> No, they're not *declared* like variables are. Dummy arguments are
> declared in the argument list. Variables are (sort of, in most cases)
> declared in one of the specification statements that can also be used to
> provide type and other attributes to dummy arguments (or, in the case of
> no IMPLICIT NONE, they are declared at first use).
> </rules lawyer>
Yes, dummy arguments are so declared like variables are. In fact,
certainly if you are in "rules lawyer" mode, they *ARE* variables,
literally and completely. (Well, most of them are. Dummy procedures and
alternate returns aren't, but dummy data arguments are variables.) This
isn't a matter of being analogous to variables in some arguable sense;
the standard defines them to literally be variables. Being in the dummy
argument list declares only one specific attribute of them - they they
are dummy arguments. The other attributes are declared, explicitly or
implicitly, just like those of other variables.
See a recent thread here about what "declaration" means in Fortran. It
is actually a tricky concept to tie down precisely. An approximate
version is that declaration is the collection of all information
specified about an entity, including implicit and explicit
specification.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| glen herrmannsfeldt 2006-09-20, 7:01 pm |
| Richard E Maine <nospam@see.signature> wrote:
(snip on dummy arguments and variable declaration)
> Yes, dummy arguments are so declared like variables are. In fact,
> certainly if you are in "rules lawyer" mode, they *ARE* variables,
> literally and completely. (Well, most of them are. Dummy procedures and
> alternate returns aren't, but dummy data arguments are variables.)
While the standard may describe them that way, I might argue that except
for the case of call by value return (copy in/out) they aren't completely
like variables. They seem to have more restrictions than variables,
especially in cases with ENTRY or optional arguments.
I do agree, though, that they are declared like variables and in
most cases work exactly like variables.
Paraphrasing a popular book, "All variables are equal but some
are more equal than others."
> This
> isn't a matter of being analogous to variables in some arguable sense;
> the standard defines them to literally be variables. Being in the dummy
> argument list declares only one specific attribute of them - they they
> are dummy arguments. The other attributes are declared, explicitly or
> implicitly, just like those of other variables.
I wonder if the OP was thinking about another language where they
are declared on the argument list. That was one change
from K&R C to ANSI C, though I believe ANSI still allows the old
declaration style.
-- glen
| |
| Richard E Maine 2006-09-20, 7:01 pm |
| glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
> Richard E Maine <nospam@see.signature> wrote:
[color=darkred]
> While the standard may describe them that way, I might argue that except
> for the case of call by value return (copy in/out) they aren't completely
> like variables. They seem to have more restrictions than variables,
> especially in cases with ENTRY or optional arguments.
Well, since almost all dummy arguments may be implemented with copy
in/out, that doesn't seem like a very restrictive set. I hope that you
wouldn't propose to define whether something counts as a variable or not
depending on a compiler-dependent implementation choice? That way lies
madness. Well, at any rate, I think it a poor choice of definition and I
won't go along with it, even conceptually.
Many variables have many kinds of restrictions. Dummy arguments are
nothing particularly unusual in this regard. They do have a set of
restrictions in some cases, but I find that set to be no different
conceptually than other restrictions having nothing to do with dummy
arguments. If you are going to use restrictions like that as a basis for
a conceptual definition of the term variable, then you are going to end
up with an awful lot of kinds of things that the standard calls
variables, but you don't.
In short, no, I don't go along with your argument that they "aren't
completely like variables". There are times when I think that the
standard uses unfortunate terminology, but this isn't one of them. I
personally think that the standard's terminology on this is a lot more
clear than whatever definition you are hinting at... which I'm not even
entirely certain of the details on - it sure looks like you are saying
that the same code has a different set of variables depending on what
compiler one uses.
P.S. Do note that the standard's definition of "variable" changed
*majorly* in f90. I'm talking about the current standard, which makes
more sense to me. In f77, arrays were never variables, for example (but
dummy arguments still were variables - at least scalar data dummy
arguments).
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Craig Powers 2006-09-20, 7:01 pm |
| Richard E Maine wrote:
> Craig Powers <enigma@hal-pc.org> wrote:
>
>
> Yes, dummy arguments are so declared like variables are. In fact,
> certainly if you are in "rules lawyer" mode, they *ARE* variables,
> literally and completely. (Well, most of them are. Dummy procedures and
> alternate returns aren't, but dummy data arguments are variables.) This
> isn't a matter of being analogous to variables in some arguable sense;
> the standard defines them to literally be variables. Being in the dummy
> argument list declares only one specific attribute of them - they they
> are dummy arguments. The other attributes are declared, explicitly or
> implicitly, just like those of other variables.
I was taking the position that the distinction of dummy arguments from
other variables was that they were arguments, and therefore appeared in
the argument list. Maybe "rules lawyer" isn't quite the right caption
for this distinction, and in retrospect it's actually not really
significant.
> See a recent thread here about what "declaration" means in Fortran. It
> is actually a tricky concept to tie down precisely. An approximate
> version is that declaration is the collection of all information
> specified about an entity, including implicit and explicit
> specification.
I was keeping that in mind, and it did inform my choice of language
(hence the "sort of, in most cases"). Although, if I'm trying to make a
fine point, it's probably not a good idea to use vague language, is it? :-p
| |
| Craig Powers 2006-09-20, 7:01 pm |
| glen herrmannsfeldt wrote:
> Richard E Maine <nospam@see.signature> wrote:
> (snip on dummy arguments and variable declaration)
>
>
> While the standard may describe them that way, I might argue that except
> for the case of call by value return (copy in/out) they aren't completely
> like variables. They seem to have more restrictions than variables,
> especially in cases with ENTRY or optional arguments.
Except for restrictions explicitly imposed by attributes (optional,
intent), it seems to me that the issues are more in correct use by the
calling procedure (hence the actual arguments associated with the
dummies) rather than the dummies themselves.
i.e. if something breaks because one supplies a literal to a dummy that
gets modified, or aliased arguments to two things that get modified, all
other things being equal it's the calling procedure that is in error by
supplying incorrect arguments (though as a practical matter, my code
generally involves a mutual agreement as to what the subroutine is going
to do with the arguments supplied to it).
| |
| glen herrmannsfeldt 2006-09-20, 7:01 pm |
| Craig Powers <enigma@hal-pc.org> wrote:
(snip regarding dummy variables)
> Except for restrictions explicitly imposed by attributes (optional,
> intent), it seems to me that the issues are more in correct use by the
> calling procedure (hence the actual arguments associated with the
> dummies) rather than the dummies themselves.
(snip regarding constants as actual arguments or aliasing)
The two I was thinking of are dummy variables of ENTRY points
betweent the declaration and the ENTRY statement. They aren't
yet variables until the first ENTRY statement referencing them.
This is even true if one enters through a specific ENTRY point
and then branches backward. (This may have made early compilers
easier to write. It probably doesn't make much difference now.)
Also, dummies for optional arguments in the case when no actual
argument is supplied.
In both these cases, unlike the constant or aliasing case, you
can't even reference the value.
Some compilers that use copy-in/copy-out allow, as an extension,
referencing variables from other ENTRY points than the one actually active.
That is, the variables actually exist separately from the dummy arguments
of the active ENTRY point. This might also be true for optional arguments.
It would be convenient for a variable to exist for an optional argument
in the case that it wasn't supplied, so that one could assign a default
value in that case. (This was discussed recently.) Optional arguments
in R do work that way.
I wasn't saying that they weren't variables, but variables of
a lower status than others. Of course the standard doesn't
refer to them that way.
-- glen
| |
| Richard E Maine 2006-09-20, 7:01 pm |
| glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
> They aren't
> yet variables until the first ENTRY statement referencing them.
Yet? I'll ignore the implication of time (i.e. run-time) and assume you
mean "yet" in a textual sense. But still... your concept has something
changing its status between variable and non-variable at different
places in the scoping unit. Ummm...
You aren't doing a very good job of convincing me that you have a
coherent definition of the term at all. I think I'll stick to the
standard's one, thank you. Perhaps this concept, whatever it is, helps
you, but I'm not finding that it helps me at all. Put it down to
different perspectives, I suppose.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
|
|
|
|
|