Re: compilation problem with module function interface definition

Richard E Maine wrote:

In article <C_Vbe.8636$XF3.3420@xxxxxxxxxxxxxxxxxxxx>,
 Phony Account <phaccount@xxxxxxxxxxxx> wrote:


(snip)

But I wonder as to the reason why the compiler does not include the function type when dealing resolving polymorphisms? Maybe because the result is not allways assigned to a typed variable.

This is a frequently asked (and discussed) question. Yes, you have the crux of the reason. Functions can be used in all kinds of contexts. My favorite example is

write (*,*) f(whatever)

An invocation like this gives no information at all about the expected result type of the function. 

(snip)

The simplest and most problematic case is the precision of real literal constants. If you have something like

x = 1.23

then the 1.23 is single precision, because that's the form of a single precision constant. It does *NOT* matter what the precision of x is; the single precision constant is defined without regard to context. The constant 1.23 is always single precision regardless of where it appears. It is fairly common for people to expect 1.23 to be accurate to double precision if x is double precision.

The C answer to this was to always make constants double. ANSI C added
the ability to specify single precision with a suffix f. Also, C normally promotes function arguments to double before calls, unless a prototype declaring the argument as float is in scope.

Unfortunately (in my opinion), some compilers encourage this expectation by silently "fixing" it up to match the common (but erroneous) user expectation. This causes bugs when the code is ported. It also causes the user to be "sloppy" about precision specification, assuming that the compiler will always fix it up. 

It also causes problems with tricks to extract the full precision.
Consider the expression 1.23D0-1.23 which should have just the extra
precision bits, but those would be lost if 1.23 was double.

> There are places where such fixup is
impossible, resulting in a mismatch of reality and user expectation. Since there are such mismatches of expectation in either case, I'm a fan of consistency - that is at least learnable. Warning messages for some detectable contexts (as advocated by several here, and as at least partially implemented in some compilers) can be a help in this. 

Subroutine arguments being one where the difference can be important.

(snip)

Functions in Fortran are very different in philosophy from, for example, in C. In C, every procedure is a function, with the case of a void result just being a special case. In Fortran, it is the case where a procedure returns a value (i.e. a function) that is special. As a consequence, Fortran style tends to use subroutines for many things where C style uses functions. Of course, style preferences do vary, so my statement on this is both an overgeneralization and a personal opinion. 

void was a later addition to C, originally those were all int.

C also has the different philosophy that = is an assignment operator,
and that expressions are allowed as statements.

1+2;   is a legal, if useless, statement in C.  A function reference
is then another form of expression ignoring the returned value.

This tends to require a language with reserved words, though, as some
statements will otherwise be confused with function references.

-- glen

.

Relevant Pages

  • Re: expression rewrites
    ... In many cases the extra precision ... Even better to use an extended precision constant. ... I agree that a single precision constant should be used ...
    (comp.lang.fortran)
  • Re: Newbie question about double precision
    ... > I just bought the F compiler from the Fortran Company, ... Assuming that '2' is the correct value for double precision for your ... compiler..... ... precision constant. ...
    (comp.lang.fortran)
  • Re: BLAS: dgemm
    ... to a procedure requiring double precision data, ... be 'single precision correct' instead of 'double precision correct'. ... Where is the compiler supposed to get ...
    (comp.lang.fortran)
  • Re: increasing width
    ... which I get every time I want to declare real. ... used to declare single or double precision variables. ... easily support more than one "kind" of single precision variable. ... have at least 13 digits of precision, ...
    (comp.lang.fortran)
  • Re: increasing width
    ... Some fellow over in sci.math.num-analysis tells me I can get at least 6 more sig figs, if instead of declaring as type real, I declare as real. ... used to declare single or double precision variables. ... easily support more than one "kind" of single precision variable. ... have at least 13 digits of precision, ...
    (comp.lang.fortran)