Fortran - ENTRY Statement Obsolescence

Author

ENTRY Statement Obsolescence

gary.l.scott@lmco.com

2005-09-16, 6:59 pm

Please don't obsolete the entry statement without providing a facility
for defining an alias for procedure names. ENTRY is used extensively
for this very purpose by commercial software packages (e.g. to provide
short F77 compliant names). Also needed is the ability to identify the
method of "decoration" or name mangling in effect (which may require an
expanded character set in some cases). And to be able to specify a
different argument list (e.g. discrete variables in one interface and
derived types in another).

Richard E Maine

2005-09-16, 6:59 pm

In article <1126879351.548493.37770@z14g2000cwz.googlegroups.com>,
gary.l.scott@lmco.com wrote:

> Please don't obsolete the entry statement without providing a facility
> for defining an alias for procedure names.

That can be done with the rename facility of the USE statement.

> ENTRY is used extensively
> for this very purpose by commercial software packages (e.g. to provide
> short F77 compliant names).

Oh, but not for f77. :-) Short f77-compliant names are expected to be a
problem in the relevant time frame? Let's see. Assuming that the
proposal to obsolete ENTRY goes through, it would be in a standard
unlikely to be implemented before 2010. And compilers conforming to that
standard would still be required to support it, because obsolescent
features are still normative.

Assuming that the then obsolescent feature was deleted from the next
standard, which would be the first allowable time, that would be, well,
making a wild guess because nobody has even started on a time frame for
such a next standard, for compilers that might come out towards the end
of the 2010's. Compilers haven't actually tended to stop supporting
deleted features, but if one assumed that standard conformance was a
requirement, I'm estimating on the order of 15 years before the feature
might become nonstandard. That's 40 years after f77. And that's assuming
some things that aren't too likely (mostly that it would be deleted the
next revision after it was made obsolescent).

You expect short f77 names to be an issue around 2020? I tried to be
pretty strict about my f77 conformance, but I gave up on 6-character
names for externals before f90 came out (though I still kept my external
names below a personal limit of 15). I thought I was quite a "laggard"
in sticking to the 6-character limit for as long as I did.

> Also needed is the ability to identify the
> method of "decoration" or name mangling in effect (which may require an
> expanded character set in some cases).

There is a feature related to that in C interop (the NAME= in BIND).
There were once more complicated versions of this feature, but it got
simplified during development. Note that ENTRY statements can't do this
anyway for many cases unless you are using nonstandard extensions. If
one is using nonstandard extensions anyway, then presumably obsoleting
something from the standard wouldn't seem to have much direct effect. It
is quite typical (and by intentional design) that many name mangling
schemes give mangled names that would not be allowed as unmangled names
(i.e. the kind you can specify in an ENTRY statement). Common examples
are mangled names that begin with underscores or that have
case-sensitive mixed case.

> And to be able to specify a
> different argument list (e.g. discrete variables in one interface and
> derived types in another).

In many cases, this kind of thing works well with a wrapper routine. One
case or other is probably copying the data to the other form anyway, so
the extra overhead of a wrapper routine probably isn't excessive.

In some other cases, optional arguments can substitute for old uses of
ENTRY, though the particular case you describe here sounds to me like
one more suited to a wrapper routine.

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

gary.l.scott@lmco.com

2005-09-16, 6:59 pm

Please don't focus too much on the F77 6-character name issue, that
wasn't the point. The point was to be able to easily create name
alias' (preferrably without writing wrappers which is someone
ridiculous). I also want the alternately named procedure to be
callable by other languages (or compilers) by using that alias that I
define (as an ENTRY statement would be). I want the basic
functionality of ENTRY. I fully understand that compilers may never
delete support for it...so why bother to delete something that has
legitimate uses. Programming style preferences vary. I don't think
there are acceptable substitutes in this case.

glen herrmannsfeldt

2005-09-16, 6:59 pm

gary.l.scott@lmco.com wrote:

> Please don't focus too much on the F77 6-character name issue, that
> wasn't the point. The point was to be able to easily create name
> alias' (preferrably without writing wrappers which is someone
> ridiculous).

Wrappers are common in Java, though I don't like it much. The
call overhead may also be much higher. Routines with optional
arguments have one that calls the one with more arguments with
the default value in place.

> I also want the alternately named procedure to be
> callable by other languages (or compilers) by using that alias that I
> define (as an ENTRY statement would be). I want the basic
> functionality of ENTRY.

My usual example is routines like Sin/Cos where the algorithm
is the same, with a slight change in argument reduction.
I have even seen assembly code using self modifying code to
change something depending on the entry point in use.

> I fully understand that compilers may never
> delete support for it...so why bother to delete something that has
> legitimate uses. Programming style preferences vary. I don't think
> there are acceptable substitutes in this case.

C doesn't have ENTRY, and there doesn't seem much desire to add it,
but then C usually has a pretty fast calling convention. Still,
I wouldn't mind if it was added.

PL/I ENTRY has the interesting feature that it will actually convert,
or attempt to convert, the RETURN value to the appropriate type for
the ENTRY point. Fortran, last I knew, EQUIVALENCEd the return
values.

-- glen

Richard E Maine

2005-09-16, 6:59 pm

In article <1126901478.177638.247500@f14g2000cwb.googlegroups.com>,
gary.l.scott@lmco.com wrote:

> The point was to be able to easily create name
> alias'

Well, except for the issue of calling from other languages, the rename
facility of USE does that quite "nicely".

> (preferrably without writing wrappers which is someone
> ridiculous).

All I can say is that tastes vary. I find wrappers to be at least
intuitive and simple. Perhaps a little "wordy", and sometimes there is a
performance issue, but I'd not apply the word "ridiculous" to them.

On the other hand, ENTRY has some, uhh... "strange baggage" that I might
well describe as ridiculous in my opinion (even if you stick to the f77
standard for it; some of the pre-f77 nonstandard versions had extra
"issues"). If all ENTRY did was provide an alias, then it sure would be
a lot simpler than what it is. I've also seen implementations of ENTRY
That had significant performance costs (even when you called the
procedure by its main entry point).

And I'm not actually sure that it is fully compatible with interlanguage
calls in all situations. In fact, I've got an interp request on exactly
that subject, which I really need to formally write up and submit.

> I fully understand that compilers may never delete support for it
> ...so why bother to delete something...

That's a continuing major debate debate (in general, not specifically
for ENTRY). Of course, if one thinks a feature is still useful for new
code, then it makes particular sense that one would not want it deleted.
But there is substantial resistance to deleting features even from
people who think that the features in question are there only for
compatibility with legacy code. A typical comment is "what does deleting
it achieve if compilers will implement it anyway?"

One of my answers to that is that the obligations that go with keeping a
feature in the standard are bigger than those that go with keeping it in
a compiler for legacy code. If you keep it in the standard, you have to
consider all the ways that it can interaction with new features. You
need to then define those interactions (even if only to disallow some
combinations - that still requires defining what it is that is
disallowed). In fact, the interp request I need to formalize relates to
the possibility that one such interaction of ENTRY with C interop might
have been overlooked.

Another answer is that keeping a feature in the standard raises the
barrier to *NEW* compilers entering the market. They have to do it to be
conforming. Of course, sometimes new compilers need to implement legacy
features anyway in order to gain user acceptance, but having a
requirement in the standard pretty much forces the choice.

I realize that these answers don't at all address the objection of
someone who thinks that a feature should be retained for continued use
in new code.

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

Sponsored Links