Dr W.W. Schulz writes:
> There were several comments on my original suggestion, some
> critical but I think while some aspects have to be clarified
> there is no convincing argument (yet) against my proposal.
Of course, to get something actually adopted requires quite a bit
better support than "no convincing arguments against". In a tie
without sufficiently convincing arguments either against or for, the
status quo almost always wins, because doing otherwise requires work.
My opinion, even though I agree with some of the points, is that I
haven't yet seen sufficiently convincing arguments for implementing
it (except perhaps for a few of the smaller points).
> If this aspect of looking
> different is important then the type part is the most logical to be banished,
> together with the RESULT part into the body of FUNCTION, however history ...
I tend to agree with that. Indeed my personal style is to never put
the type on the function statement. But my style preferences are not
sufficient reason to make a requirement in the standard (particularly
a requirement that would invalidate much existing code).
Perhaps part of what I don't like about the proposal is that I feel it
moves in the wrong direction, putting more stuff in the function
statement, instead of taking stuff out.
I personally tend to view function...end primarily as syntactic
delimitters. (Yes, I'm one of those people that always puts RETURN
before my END statements because I don't consider END to be
legitimately an executable statement; of course this is my style, not
the standard).
> > To declare an external function you could say
> > REAL,EXTERNAL,PUBLIC :: foo
> ^^^^^^
> Why should I want to export an external function? It only makes sense in the
> current scoping unit to declare that foo is a procedure.
I guess some of my existing code doesn't make sense. Of course, you
might agree with that. :-(
Whereas I mostly try to avoid external functions at all, there are
exceptions. In my case, most commonly for things like C routines or
other truyly external libraries. If I'm using an external library
designed for C or f77 (as quite a lot of them are), I almost always
"wrap" it in a module. Most commonly specified with interface bodies,
but there are a few cases where I couldn't do that.
I do agree with the concept of allowing some of the attributes that
now get implicitly conferred to be stated explicitly. There are quite
a few of these. Among them are (and these aren't proposed spellings),
NONSAVE (which we now can only specify by the omission of SAVE, and
sometimes that doesn't even do it - per recent threads here),
SCALAR (which we no specify only by the omission of arrayness),
LOCALVARIABLE (really a bad spelling, but gives you the idea; this
is to specify that something like "real, localvariable :: x" is indeed
a local variable; otherwise it might later turn out to actually be
an external function), and some others.
But I'm not so fond of adding attributes to the function statement.
--
Richard Maine
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|