Re: Statement functions

James Giles wrote:
Joe Krahn wrote:

Just another minor feature suggestion:
Why not include an optional "FUNCTION" keyword at the beginning of
function statements? It would be a simple way to avoid ambiguity with
array assignment, especially in the case of an internal subprogram.


It would have to be "FUNCTION ::". Otherwise you wouldn't
be able to tell the difference in fixed form. It isn't so much an
ambiguity as it is easily susceptible to error. If the host (or
a module you failed to say ONLY with) has an array of the
same name and you forget to give a local type declaration
for it, the lisn *is* an assignment. This is not worse than
(and less common than) other instances where an intended
local entity has a different meaning than desired because
the programmer failed to make the local declaration and
accidentally got something from outside instead.

However, the thing you recommend would be useful in another
way. It would identify the thing as a statement function without
specifying a type. The rule could be that statement functions
declared that way were completely generic. So:

Function :: double(a) = a + a

This function would be defined on any type for which the plus
operator as defined. And, it would return the type that the plus
operator on that type of argument would notmally return. In
this case, not only is a separate declaration of the type of DOUBLE
not required, it's not permitted. And, any separate declaration
of A is irrelevant since in the above, A is a dummy argument
whose scope is for that single statement only.

Note, when I say that the function is completely generic, it
means that even if the argument type is one that doesn't have
an intrinsic plus operator, if there's an overload for that type,
ít's still meaningful to use the statement function.

(I've been thinking of using the keyword "STMT :: ".)


So, I guess the only advantage of a "FUNCTION ::" prefix is code readability. Of course, it could be even more readable if the type declaration and function were combined:

REAL, FUNCTION :: x(y) = ...

Or, for your idea of the generic form:

GENERIC, FUNCTION :: x(y) = ...

or, because the result is implicit:

IMPLICIT, FUNCTION :: x(y) = ...

Unlike regular functions, a statement-function return type can be easily defined as the type you would get from evaluating the expression made from substituting the arguments. Essentially, it's the same effect as a macro.

As for the keyword STMT, I'm sure that STATEMENT is a better Fortran-istic choice.

Joe
.

Relevant Pages

  • Re: Statement functions
    ... It would be a simple way to avoid ambiguity with ... array assignment, especially in the case of an internal subprogram. ... same name and you forget to give a local type declaration ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: Need help on PHP for MPE/ix
    ... If one item is an array, it must be declared as such in the list ... So, please show us the declaration of the record buffer, and its ... Of Pavan Kumar Rati ... Need help on PHP for MPE/ix ...
    (comp.sys.hp.mpe)
  • Re: Difference between C and advanced C
    ... static and type qualifiers in parameter array declarators ... trailing comma allowed in enum declaration ... additional predefined macro names ... additional strftime conversion specifiers ...
    (comp.lang.c)
  • Re: avoiding writing an interface blocks
    ... the reason this needs an explicit interface is because of the ... example, an array, and not specify the argument types. ... type, period, with any kind of declaration. ... C-type pointers, including to ...
    (comp.lang.fortran)
  • Re: Does the order of declarations matter?
    ... > subroutine sub ... > Or must the declaration for N appear before the declaration ... parameter or array bound shall be specified in a prior ...
    (comp.lang.fortran)