Prev: parameter incosistency
Next: Suppressing intrinsic assignment of derived type
From: Richard Maine on 20 May 2010 17:06
Gordon Sande <Gordon.Sande(a)gmail.com> wrote:
[about adjustable array bounds]
> I would guess that the folks who documented Fortran IV looked at the generated
> code and asked what it depended up. The answer was that it needed a value that
> existed at the beginning of the program like those of the arguement list or
> in common and that the execution prefix would set up all the necessary
> addressing constants so it would be OK to change those values. They did a good
> job. Perhaps too good of a job as the flexibility to change the adjustable
> dimension variables seems to be poor programmng practice.

Note that this same flexibility continues for more "newfangled" forms
such as automatic arrays, and even automatic type parameters. The values
are used on entry and there is no restriction against changing the
variable afterwards.

So maybe times aren't all that different. I doubt that anyone looked at
the generated code from some compiler to decide how automatic arrays
should be specified in the f90 standard. They probably did think in
general about what would be needed, but I doubt it was by examining the
generated code from some compiler.

There is certainly still a tendency to avoid putting restrictions in the
standard for purely progamming style reasons. I've listened to some
debates on things like that - not this particular one, but others that
go somewhat like "A programmer would have to be stupid to write
something like this; let's prohibit it", which is usually answered by
something like "the standard doesn't try to prohibit stupidity; if it
did, there would be plenty of other things prohibitted."

If there were a prohibition against changing the value of the variables
in question after entry, someone would be sure to complain that it was
an arbitrary prohibition that prevented them from doing something
useful.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 20 May 2010 17:38
mecej4 <mecej4_nospam(a)operamail.com> wrote:
> On 5/20/2010 1:17 PM, glen herrmannsfeldt wrote:
>> mecej4<mecej4_no_spam(a)operamail.com> wrote:
>> (snip)

>>> I have a copy of the IBM VS Fortran Rel.1.1 Reference Manual, dated
>>> 1982. It claims to be Fortran 77 + IBM extensions. Page 22 covers the
>>> topic of adjustable dimensions in great detail:
>
>> IBM is pretty good at marking extensions in their manuals,
>> usually by giving them a grey background.

>>> "...Instead, the array declarators appearing in an explicit
>>> specification statement or DIMENSION statement in the subprogram may
>>> contain dummy arguments or _variables_in_common_ (italics mine) that are
>>> integer variables of length 4 to specify the size of the array."

>> I believe the COMMON case is standard Fortran 66. Is it grey?

Looking at the Fortran 66 standard, I don't see that it allows
for the dimensions to be in COMMON. The length 4 part should
have been marked as an extension, thought that is the default
length.

> No, this manual appears to have been "typeset" on a Printronix before
> copying. IBM extensions are marked by surrounding them by lines. The
> sections that I quoted here are NOT marked as extensions.

>>> Later on, on the same page, it says:

>>> "Integer variables in the explicit specification or DIMENSION
>>> statement that provide dimension information may be redefined within the
>>> subprogram but the redefinitions have no effect on the size of the
>>> array. The size of the array is determined at the entry point at which
>>> the array information is passed."

It seems that neither Fortran 66, nor S/360 S/370 Fortran IV allow the
variables to be redefined. Though with the grey method it is much
easier to indicate individual words as extensions, which IBM did
in the S/360 and S/370 manuals.

-- glen
From: jfh on 20 May 2010 17:51
On May 21, 6:17 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
> mecej4 <mecej4_no_s...(a)operamail.com> wrote:
>
> (snip)
>
> > I have a copy of the IBM VS Fortran Rel.1.1 Reference Manual, dated
> > 1982. It claims to be Fortran 77 + IBM extensions. Page 22 covers the
> > topic of adjustable dimensions in great detail:
>
> IBM is pretty good at marking extensions in their manuals,
> usually by giving them a grey background.
>
> >     "...Instead, the array declarators appearing in an explicit
> > specification statement or DIMENSION statement in the subprogram may
> > contain dummy arguments or _variables_in_common_ (italics mine) that are
> > integer variables of length 4 to specify the size of the array."
>
> I believe the COMMON case is standard Fortran 66.  Is it grey?

It is standard f66, in section 7.2.1.1. The thing that surprised me
about f66 arrays when I looked up the standard was 5.1.3.3, which says
a subscript expression must be written as one of these constructs: c*v
+k, c*v-k, c*v, c+k, c-k, v, k, where c and k are integer constants
and v is an integer variable reference. So if A was a one-dimensional
array, X a scalar and N an integer variable, these statements would
presumably have been non-standard:

X = A(N+1)
X = A(N**2)

-- John Harper
From: Richard Maine on 20 May 2010 18:30
jfh <john.harper(a)vuw.ac.nz> wrote:

> It is standard f66, in section 7.2.1.1. The thing that surprised me
> about f66 arrays when I looked up the standard was 5.1.3.3, which says
> a subscript expression must be written as one of these constructs: c*v
> +k, c*v-k, c*v, c+k, c-k, v, k, where c and k are integer constants
> and v is an integer variable reference. So if A was a one-dimensional
> array, X a scalar and N an integer variable, these statements would
> presumably have been non-standard:
>
> X = A(N+1)
> X = A(N**2)

Well, your N+1 example is ok as I recollect. I think you must have a
typo in there somewhere, as the c+k and c-k cases make no sense (at
least not in terms of matching my recollection). I bet they were more
like v+k and v-k. Your N**2 example is certainly non-standard.

To me, a much more "interesting" oddity that I recall here was than n+1
was ok, but 1+n was not.

I put this in a general category of f77 allowing expressions in most
places where expressions could plausibly make sense, while f66 was
awfully restrictive. There are several other cases. For example, my f66
code was full of messes like the following because DO limits could not
be expressions (and also because of the one-trip problem)

ip1 = i+1
jm1 = j-1
if (ip1 .gt. jm1) goto 250
do 200 k = ip1, jm1
...
200 continue
250 continue

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Richard Maine on 20 May 2010 18:30
jfh <john.harper(a)vuw.ac.nz> wrote:

> On May 21, 6:17 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
> > mecej4 <mecej4_no_s...(a)operamail.com> wrote:
> >
> > > "...Instead, the array declarators appearing in an explicit
> > > specification statement or DIMENSION statement in the subprogram may
> > > contain dummy arguments or _variables_in_common_ (italics mine) that are
> > > integer variables of length 4 to specify the size of the array."
> >
> > I believe the COMMON case is standard Fortran 66. Is it grey?
>
> It is standard f66, in section 7.2.1.1.

I think you need to reread that part a bit more carefully. It mentions
COMMON, but not in this context. The mention of COMMON is just to
explain that an array declarator can appear in a COMON statement. That
wasn't the question here. The question here was whether the variables in
an array declarator could be in COMMON.

On the question at hand, 7.2.1.1.2 first says "The dummy argument list
of the subprograms must contain the array name and the integer variable
names that represent the adjustable dimensions."

That ought to finish it, as dummy arguments can't be in common (see
7.2.1.3, which says "no dummy arguments are permitted").

But just in case we got it right the first time, the last sentence of
7.2.1.1.2 confuses the issue by redundantly saying "In a subprogram, a
symbolic name that appears in a COMMON statement may not identify an
adjustable array."

As f90/f95 editor, I sure would have given a hard time to anyone who
tried to put something like that sentence in. After saying that both the
array name and the integer variable names have to be dummy arguments, we
then feel it necessary to remind people that this means the array can't
be in common. I suppose this implies that the integer variables can?
Nope. We just thought we'd say this about one of them but not the other
just to make sure people thought there was a difference. And then there
is the obvious implication that it must be ok to do this in the main
program because the restriction explicitly says it applies only to
subprograms. Argh! Yes, I've let things as bad or worse slip through.
That doesn't keep me from cringing when I read things like this.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: parameter incosistency
Next: Suppressing intrinsic assignment of derived type