Re: double confusion

On 2006-07-17 18:11:11 -0300, glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx> said:

Gordon Sande wrote:
On 2006-07-17 15:38:52 -0300, glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx> said:

(snip)

Doesn't IMPLICIT have the same scoping problem as other declarations?

The OP thought that a declaration of the following function would
be used by the preceding program because they were in the same file.
If there had been an IMPLICIT NONE in the main there would have been
diagnostics about the missing declaration of the function.

OK, but even better would be IMPLICIT NONE for each subroutine
and function...

The OP was doing fine inside the two units. The trouble was between
the two units. As I recall, all variables were declared with the
single exception of the external function which is what was causing
the trouble. There was a secondary confusion of what was the beginning
of the main program as somehow the assumption was that declarations
early in the "file" would apply "globally".

Sometimes it helps to point out that separate compilation can be
taken to also mean on separate days or even separate machines
or in any order. At that point the light sometimes go on and they
get the impact of separate compilation. The compilers that are
helpful by remembering earlier usages or declarations obscure the
effect of separate compilation and lead to incorrect "folk syntax
rules" by and for folks who have never bothered to read a manual.
Sometimes such folk syntax rules are wrong and one gets things like
this OP.

The IMPLICIT NONE would have made it rather explicit that there was
no declaration of the double precision function in the scope of the
main program. The problem was to purge the scope of default declarations
so the OP would know what declarations the compiler was applying. The
problem was the implicit defaults and the F77 linking rules allowing
a program into execution where it did not work correctly.

I believe some languages will carry declarations forward, but not
backward. For the case in question, I believe C would give an error
when it found the function definition that didn't agree with the implicit declaration in main. If the function came first, that would
declare its return type. As we know, Fortran doesn't do that.

The OP had the "look and feel" of someone who expected the C rules
on file scope to apply to Fortran separate compilations. So the
question was how to make it easily explicit that something was
missing. Undoubtedly some poor overworked soldier who had been told
"You're a programmer. Deal with this."

I think this one confused me a while when I started learning C, applying
the Fortran rules to C.

(snip)

-- glen


.

Relevant Pages

  • Re: double confusion
    ... Doesn't IMPLICIT have the same scoping problem as other declarations? ... on file scope to apply to Fortran separate compilations. ... Fortran has no notion of file scope so the beginning is actually the ...
    (comp.lang.fortran)
  • Re: Jumping into block of an if construct
    ... > Fortran since 90 can indeed declare and allocate Alocally. ... > be a 'specification expression' which basically must be mathemtically ... And Fortran declarations do seem to me to be sequenced in some ... The motivation for this in the standard seems to be to ...
    (comp.lang.fortran)
  • TYPE declaration/statement in Fortran 77 code
    ... I have a piece of code (Fortran 77) that contains a lot of these TYPE ... As such, it doesn't compile with any compiler I tried (gfortran, g95 ... makes it compilable with ifort. ... I couldn't find anything related to TYPE declarations in this context, ...
    (comp.lang.fortran)
  • Re: double precision g77
    ... so changed all REAL declarations to DOUBLE PRECISION and changed FUNCTION ... If you don't use implicit none, then changing all the REAL declarations ... Changing declarations does nothing about literal ...
    (comp.lang.fortran)
  • Re: Module Fortran 90
    ... implicit none ... integer,dimension, pointer:: A ... is not declarations that are accessed from a module. ... compiler), showing exactly what you did, and exactly what the resulting ...
    (comp.lang.fortran)