Re: compilation problem with module function interface definition

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

> As a Donald nicely exposed, the other cardinal rule that I broke (I have
> the f95/03 explained book) is lack of reading and comprehension skills.
> I re-read Section 5.18 with care, and sure enough it all makes sense
> now.

Things often make more sense after you understand them. You are scarcely
alone in this. :-(

> 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.

This is actually part of a very broad principle that applies to many
other things in addition to functions - that the result type and value
of an expression does not depend on context. This principle is pretty
much endemic to the whole language; as soon as you start to violate it,
all kinds of subtle complications start cropping up. I don't have time
to go into the details now (and they are many enough and subtle enough
that I probably couldn't even remember all of them; for that matter,
wouldn't surprise me if there were some that nobody had yet realized).
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.

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. 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.

> This could be dealt
> with with a more obscure invocation of the function which would also
> specify the desired result type. But that is a completely different thread.

I've seen procedures (even subroutines) implemented like that - where
there is an argument whose sole purpose is disambiguation. Sometimes its
value isn't even used - all that matters is its type. I'm not personally
very fond of the style in general, but I've seen it done. (The Fortran
standard even has a few cases).

As a side note, let me comment that the main benefit of a function over
a subroutine is that you can use the function in the middle of an
expression without assigning its result to a temporary variable. If a
function were designed in such a way that it could only work in a
trivial assignment context, then one might as well use a subroutine.
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.

As another side note on terminology. Generics are not called polymorphic
in F2003. There is certainly a relation to polymorphism because the same
name can be used for something of multiple types. However, f2003
reserves the term polymorphism for things whose type can vary
dynamically at run time, rather than just statically at compile time.
The usage was clear enough in the context of the current thread, but I'd
be concerned that you would have confusions in the future if you think
of generic procedures as polymorphic.

--
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
.

Relevant Pages

  • Re: prePEP: Decimal data type
    ... with arbitrary precision I'd get the right result? ... The Context still needs to be defined, ... The integrity of my calculations may be impacted. ... Emile van Sebille ...
    (comp.lang.python)
  • Re: prePEP: Decimal data type
    ... I guess I am missing the "Context" info, ... >Remember that the precision is in the context. ... >You just specify in the context what type of rounding you want. ... and appear to evaluate rhs expressions with ...
    (comp.lang.python)
  • Re: Is C close to the machine?
    ... This was in the context of deterministic results. ... If you want a sum in IEEE754 ... (i.e. to infinite precision) ... determism means getting the same answers over ALL orderings. ...
    (comp.arch)
  • Re: defgeneric, defstruct and no CLOS
    ... leverage the polysemy of verbs to mean different things, in situations where the context would disambiguate. ... That context is just computer language syntax. ... Any domain requiring precision comes up with a precise albeit constraining vocabulary where there is one word for everything and everything has one word. ...
    (comp.lang.lisp)