Fortran - in defense of "star" notation

Author

in defense of "star" notation

e p chandler

2005-05-23, 8:57 pm

Instead of forking another recent thread on this subject, I would like
to propose something here that might explain a use for the non-standard
notation seen in INTEGER*2, etc.

IMO sometimes it is a good idea to write code that sticks out and says
"I require a 2 byte integer, no more, no less."

1. Mixed language programming or making system calls, particularly
under MS-DOS or MS-Windows. Portablity does not matter much here.

2. Small program fragments which depend upon the hardware
representation.

Used sparingly, this notation makes it explicit that the programmer is
doing something unusual, non-standard and non-portable.

Steven G. Kargl

2005-05-23, 8:57 pm

In article <1116874763.847400.76430@o13g2000cwo.googlegroups.com>,
"e p chandler" <epc8@juno.com> writes:
> Instead of forking another recent thread on this subject, I would like
> to propose something here that might explain a use for the non-standard
> notation seen in INTEGER*2, etc.
>
> IMO sometimes it is a good idea to write code that sticks out and says
> "I require a 2 byte integer, no more, no less."

AFAIK, the Standard does not have a concept of "byte". At best,
INTEGER*2 could be interpreted to be an integer that occupies
2 storage units (whatever these may be).

--
Steve
http://troutmask.apl.washington.edu/~kargl/

David Flower

2005-05-23, 8:57 pm

It also has the advantage of not being ambiguous:

INTEGER*4 I

means a 4-byte integer on all modern compilers with which I am
familiar;

however,

INTEGER (KIND=4)

means a 4-byte integer on most compilers, but for Salford FTN95, it
means an 8-byte integer.

Richard E Maine

2005-05-23, 8:57 pm

In article <1116874763.847400.76430@o13g2000cwo.googlegroups.com>,
"e p chandler" <epc8@juno.com> wrote:

> IMO sometimes it is a good idea to write code that sticks out and says
> "I require a 2 byte integer, no more, no less."

Of course. But there are also all kinds of different scenarios where one
has some specific requirement for a kind with a particular property. I
don't think that a distinct syntax for each such requirement makes
sense. I'd say that distinctive names make a lot more sense. I have
requirements like this in some of my own code... and I have a named
parameter that I define for it. I happen to name mine i2_kind, but
choose your own naming convention. I think that a suitably chosen name
can be a lot more clear than a special syntax of *2.

I well understand the need for the feature, but I don't agree that the
special syntax is a very good fit to the need.

For that matter, with C interop, f2003 even has a standardized set of
names for some such things, particularly including a 2-byte integer
(that would be C_INT8_T in the ISO_C_BINDING standard module). I have
advocated for providing some corresponding standardized parameter names
outside of the C interop context. I have argued (along with other
points) that I think it anomalous that Fortran now has better support
(via C interop) for exact specification of common integer sizes than for
exact specification of common floating point sizes.

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

e p chandler

2005-05-23, 8:57 pm

Steven G. Kargl wrote:
> In article <1116874763.847400.76430@o13g2000cwo.googlegroups.com>,
> "e p chandler" <epc8@juno.com> writes:
like[color=darkred]
non-standard[color=darkred]
says[color=darkred]
>
> AFAIK, the Standard does not have a concept of "byte". At best,
> INTEGER*2 could be interpreted to be an integer that occupies
> 2 storage units (whatever these may be).
>
> --
> Steve
> http://troutmask.apl.washington.edu/~kargl/

Please look back at the original context. I'm deliberately writing
non-standard conforming code.

e p chandler

2005-05-23, 8:57 pm

Richard E Maine wrote:
> In article <1116874763.847400.76430@o13g2000cwo.googlegroups.com>,
> "e p chandler" <epc8@juno.com> wrote:
>
says[color=darkred]
>
> Of course. But there are also all kinds of different scenarios where
one
> has some specific requirement for a kind with a particular property.
I
> don't think that a distinct syntax for each such requirement makes
> sense. I'd say that distinctive names make a lot more sense. I have
> requirements like this in some of my own code... and I have a named
> parameter that I define for it. I happen to name mine i2_kind, but
> choose your own naming convention. I think that a suitably chosen
name
> can be a lot more clear than a special syntax of *2.
>
> I well understand the need for the feature, but I don't agree that
the
> special syntax is a very good fit to the need.
>

Except perhaps on older hardware and in older computing environments
where Fortran 90/95+ is not available.

I also hope that interoperability requirements make this a non problem
in the near future.

Richard E Maine

2005-05-23, 8:57 pm

In article <1116877463.922435.42030@g44g2000cwa.googlegroups.com>,
"e p chandler" <epc8@juno.com> wrote:

> Richard E Maine wrote:

[color=darkred]
> Except perhaps on older hardware and in older computing environments
> where Fortran 90/95+ is not available.

Oh. I didn't appreciate that you were talking about existing code and
old environments. It sounded to me like you were advocating for the use
of this syntax in new code, particularly with the citations of what "all
modern compilers" do with the syntax.

I don't find it particularly necessary to justify the use of those
syntaxes in old f77 codes. There was no alternative way, standard or
non-standard to specify many things that we now can do in f77. You cited
integer*2, but this being Fortran, real numbers tend to be pretty near
and dear to our hearts. Certainly *MANY* Fortran 77 programmers used the
real*8 syntax to indicate that they needed 64-bit reals. I did. There
wasn't a good alternative. If you said just REAL, you only got 32-bits
on many machines, and that wasn't enough. If you said DOUBLE PRECISION,
then you got 128 bits on some machines, and that was too expensive (in
time and/or memory).

It is widely recognized that f77 was deficient in portable specification
of numeric properties. That's why major new features relating to this
were introduced in f90. You didn't need to be doing anything horribly
machine-specific to run into this issue. Pretty much anyone with any
kind of requirement on precision ran into it because there was no
portable way to specify precision.

We did what we had to do to get the job done. Details varied, but
declarations like REAL*8 were certainly among the tricks used.

But if you are talking about that era, then it was not even close to
accurate that all compilers that were then "modern" compilers supported
the notation.

If you are talking about an environment today where Fortran 90/95+ is
not available, then I'm afraid you are talking about some pretty small
niche situation. If you are in the niche, then do what you have to do,
and you don't need to justify it to us (or anyone). But I don't think
this makes much sense as any kind of widely applicable advice. I would
say that the closest widely applicable advice is to broaden ones
perspective to find out what actually is available today. I would say
that very few people today are actually in environments accurately
described like that, though a larger number of people might think that
they are. And other people might just choose to stick with f77, which
is, of course, their prerogative, but I don't think it needs
"justification" like this; in fact, I think it sits better as a choice
made from personal preference or being used to it. The "justification"
just sounds like an attempt at other rationalization to me.

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

e p chandler

2005-05-23, 8:57 pm

Richard E Maine wrote:
> In article <1116877463.922435.42030@g44g2000cwa.googlegroups.com>,
> "e p chandler" <epc8@juno.com> wrote:
>
>
that[color=darkred]
>
environments[color=darkred]
>
> Oh. I didn't appreciate that you were talking about existing code and

> old environments. It sounded to me like you were advocating for the
use
> of this syntax in new code, particularly with the citations of what
"all
> modern compilers" do with the syntax.
>

Sorry, but someone else made that remark. I simply wanted to explain
its use in very limited circumstances. What came to mind was DOS and
Win 3.1.

Richard E Maine

2005-05-23, 8:57 pm

In article <1116885312.802912.151780@g47g2000cwa.googlegroups.com>,
"e p chandler" <epc8@juno.com> wrote:

> Richard E Maine wrote:
> particularly with the citations of what "all
>
> Sorry, but someone else made that remark.

Oh. So I see. Sorry, for confusing the mixed messages from multiple
posters.

> I simply wanted to explain
> its use in very limited circumstances. What came to mind was DOS and
> Win 3.1.

Oh. Ok. I guess I don't see why you think you'd need to defend it in
that case, or why this is particular to star notation. There are lots of
other things widely advocated in the newsgroup that you won't be able to
do there either (like pretty much anything new to f90).

But then, I also see no need to ask you to defend why you are defending
it. :-) I'll just accept that I misunderstood what you were getting at.

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

David Flower

2005-05-24, 8:57 am

'If you are talking about an environment today where Fortran 90/95+ is
not available, then I'm afraid you are talking about some pretty small
niche situation.'

I am told, I don't know how reliably, that the most widely used FORTRAN
compiler at the present time is g77.

Throw in large amounts of excellent legacy software, and it is clear
that FORTRAN77 is still enormously important.

Those of us who wrote in FORTRAN before the advent of the 77 standard
are well aware that none of the extensions introduced by the 90
standard were as useful as any one of the top half dozen in the 77
standard.

Richard E Maine

2005-05-24, 3:59 pm

In article <1116920168.433966.21110@z14g2000cwz.googlegroups.com>,
"David Flower" <DavJFlower@AOL.COM> wrote:

[quoting me in this first para]

> 'If you are talking about an environment today where Fortran 90/95+ is
> not available, then I'm afraid you are talking about some pretty small
> niche situation.'
>
> I am told, I don't know how reliably, that the most widely used FORTRAN
> compiler at the present time is g77.

I could believe that. I also don't know whether it is accurate or not,
but that doesn't matter. But that isn't responsive to what I said.
Although I certainly fail in it on occasion, I try to use words
precisely. Here, in particular, I used the word "available" quite
intentionally; its meaning is not particularly close to "most widely
used". The most widely used compiler is probably some variant of Visual
Basic or some such thing, but that isn't very relevant to what I was
saying either.

> Throw in large amounts of excellent legacy software, and it is clear
> that FORTRAN77 is still enormously important.

I have never, and do not now, claim otherwise. I've written quite a bit
of legacy Fortran 77 software myself. Indeed, the body of Fortran 77
software is a contributor to the importance of Fortran 90/95+, since it
is also Fortran 90 software.

I note as an aside, since you specifically mention g77, it is not
particularly noted for accepting a wide variety of nonstandard
constructs sometimes used in legacy f77 codes. In particular, g77
doesn't accept either Cray pointers or Vax records. I have had quite a
few people ask about porting legacy codes that do not work with g77, but
do work with some commercial f90 compilers. I helped purchase an f90
compiler for one system here specifically because of a legacy code that
did not work with any compiler that we otherwise had available.

> Those of us who wrote in FORTRAN before the advent of the 77 standard
> are well aware that none of the extensions introduced by the 90
> standard were as useful as any one of the top half dozen in the 77
> standard.

Hmm. I see a bit of agenda here. Well, I'll not argue the point. (I
don't agree, but I'll not argue).

Quite the opposite, I will say that it is perfectly fine with me if, for
whatever reason, you choose to continue to use compilers that are
restricted to f77. Not that you need my approval anyway. There is
nothing about it to defend (note the subject of this thread).

I am unlikely to spend much of my time in helping you work around what I
regard as shortcomings in sticking with f77, but since I don't see you
asking for my help in that, it doesn't much matter.

And when people do ask for my advice on the subject, I will continue to
give the advice that I consider appropriate. But I am on no cru

e to
convince you of anything, so no "defense" is needed. I remain puzzled
about what point is being made, but I'll go back to trying to help those
people who want my help.

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

Dave Thompson

2005-05-31, 4:00 am

On Mon, 23 May 2005 12:26:33 -0700, Richard E Maine
<nospam@see.signature> wrote:

> In article <1116874763.847400.76430@o13g2000cwo.googlegroups.com>,
> "e p chandler" <epc8@juno.com> wrote:
>
>
> Of course. But there are also all kinds of different scenarios where one
> has some specific requirement for a kind with a particular property. <snip>
> I well understand the need for the feature, but I don't agree that the
> special syntax is a very good fit to the need.
>
> For that matter, with C interop, f2003 even has a standardized set of
> names for some such things, particularly including a 2-byte integer
> (that would be C_INT8_T in the ISO_C_BINDING standard module). I have
> advocated for providing some corresponding standardized parameter names
> outside of the C interop context. <snip>

Obviously you mean C_INT16_T, at least for "normal" machines with
8-bit bytes and supporting (in C) a 16-bit integer type, neither of
which is totally guaranteed. If the former is false, I'm not sure the
OP really wanted "exactly 2 bytes" even when byte is 47 bits. If the
latter is false you get a compile error, and presumably should occur
only if the underlying machine doesn't have a 16-bit type in which
case if you demand to have one you're obviously up the cr

.

- David.Thompson1 at worldnet.att.net

Sponsored Links