Declaration order
ma...@athenavisual.com
but not with Compaq v6.6:
real*8 myVal(myn)
integer myn
common /myCommon/ myn
The declaration of the array comes before the declaration of its
dimension which comes through a common block. Any takes?
David Flower
This is illegal code unless you also have a PARAMETER statement
supplying the value of myn
Dave Flower
michael...@compuserve.com
I beg to differ:
subroutine sub
real*8 myVal(myn)
integer myn
common /myCommon/ myn
myval = 3.3
print *, myval(1)
end
integer myn
common /myCommon/ myn
myn = 4
call sub
end
Thus, it could be an automatic array.
Regards,
Mike Metcalf
Dick Hendrickson
give the error message. But, I believe it's an ordering
problem. You're using "myn" before you've completely
declared it. Compaq v6.6 is a relatively old compiler and
the rules for how things must be ordered in the declarations
have changed over the years. I don't remember for sure what
is what here, and a quick look at the standard didn't help.
It will surely work if you move the real statement to be after the
common statement.
You might also try turning on standards conformance for both
g95 and v10.x and see if they are letting you get away with
something.
Dick Hendrickson
ma...@athenavisual.com
>
> - Show quoted text -
The Compaq compiler shows the following errors.
xxxx.FOR(245) : Error: This name does not have a type, and must have
an explicit type. [MYN]
xxxx.FOR(245) : Error: A specification expression is invalid.
[MYVAL]
The question is why in the world the order of the declaration
statements would be of any value. It makes sense for executable
statements but for declarations statements??
Steve Lionel
> The Compaq compiler shows the following errors.
>
> xxxx.FOR(245) : Error: This name does not have a type, and must have
> an explicit type. [MYN]
>
> xxxx.FOR(245) : Error: A specification expression is invalid.
> [MYVAL]
>
> The question is why in the world the order of the declaration
> statements would be of any value. It makes sense for executable
> statements but for declarations statements??
My guess is that if you used the same options with the Intel compiler
that you did with CVF you'd see identical behavior. There is a rule
about specification expressions, (here, the myn as the bounds for array
myVal) which requires that the datatype of entities in the expression be
declared "previously" if they are not correct implicitly. In your case,
you have IMPLICIT NONE or, more likely, /warn:declarations in your CVF
options, which forces you to declare all variables. That means that MYN
is not implicitly integer and therefore you get an error. It does not
count that you declared MYN to be integer in a later statement - some
compilers allow that as an extension, but CVF and ifort do not.
The fix is to move the "integer myn" to before the declaration of myVal.
For clarity, I'd recommend moving the COMMON declaration along with
it. This way you will be standard-conforming.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
nm...@cam.ac.uk
Steve Lionel <steve....@intel.invalid> wrote:
>
>My guess is that if you used the same options with the Intel compiler
>that you did with CVF you'd see identical behavior. There is a rule
>about specification expressions, (here, the myn as the bounds for array
>myVal) which requires that the datatype of entities in the expression be
>declared "previously" if they are not correct implicitly. In your case,
>you have IMPLICIT NONE or, more likely, /warn:declarations in your CVF
>options, which forces you to declare all variables. That means that MYN
>is not implicitly integer and therefore you get an error. It does not
>count that you declared MYN to be integer in a later statement - some
>compilers allow that as an extension, but CVF and ifort do not.
A very annoying "gotcha" for people accustomed to less restrictive
languages, such as Algol 68.
It might have been possible to relax that at Fortran 90, as I don't
think that any conforming Fortran 77 program could distinguish the
two specifications, but I don't think that it could be done now.
Regards,
Nick Maclaren.
Richard Maine
> The question is why in the world the order of the declaration
> statements would be of any value. It makes sense for executable
> statements but for declarations statements??
Two reasons.
1. Without some restrictions on the ordering of declaration statements,
it is trivial to construct examples of circular dependencies that are
ambiguous. A trivial case is
integer(kind=kind(j)) :: i
integer(kind=kind(i)) :: j
1.5 :-) Closely related. It is also possible to construct circular
dependencies that recurse infinitely, such as
type type_a
type(b) :: x
end type
type type_b
type(a) :: y
end type
2. It can make the compiler's job harder if important information about
a symbol isn't available until after the symbol has been used.
Now it can be argued that the current standard goes farther than needed.
Compiler technology doesn't really have a lot of trouble dealing with
item 2. And the restrictions are far more broad than needed to avoid the
cases in item 1 and 1.5.
So the exact restrictions are arguable, but it is "evident" that some
restrictions are needed, which would seem to answer your question.
Your particular case (like many of them in practice) is in the category
of getting hit by restrictions that are simplified to be broader than
really needed, which is why some compilers allow it as an extension.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
><ma...@athenavisual.com> wrote:
>
>> The question is why in the world the order of the declaration
>> statements would be of any value. It makes sense for executable
>> statements but for declarations statements??
>
>Compiler technology doesn't really have a lot of trouble dealing with
>item 2. And the restrictions are far more broad than needed to avoid the
>cases in item 1 and 1.5.
>
>So the exact restrictions are arguable, but it is "evident" that some
>restrictions are needed, which would seem to answer your question.
Debatably. Algol 68 showed that you didn't need to restrict the
order. On the other hand, the order-independence of that language
did confuse the sort of user for whom programming was the output
of a stream of consciousness :-)
Fortran 90 could have gone that way, but didn't. It chose to take
the order-dependent path. Your statement that some restrictions are
needed is correct, of course, but there isn't an absolute need for
them to be ordering restrictions.
Regards,
Nick Maclaren.
Richard Maine
> Fortran 90 could have gone that way, but didn't. It chose to take
> the order-dependent path. Your statement that some restrictions are
> needed is correct, of course, but there isn't an absolute need for
> them to be ordering restrictions.
Oh. True. In explaining why restrictions are needed, I forgot (um, I
mean oversimplified :-)) that some possible variants of the restrictions
don't use ordering. Ordering just happens to be a relatively simple one
to express in standard-speak. It isn't without its complications (not at
all), but it can be simpler than writing precise conditions that
guarantee a finite, unique result.
One proposal that I've heard made, at least informally, is that the
Fortran standard doesn't need to lay out the explicit conditions, but
could instead just express it more generally as that the solution must
be finite and unique (or other simillarly general terms). That is
perhaps a bit radical in terms of language standard traditions, but it
isn't necessarily any less precise and rigourous. It just avoids putting
all of the math into the standard. I found the idea intriguing.
Since most of the things that people try to write in real code are
suitable, that would avoid a lot of the questions like the one of this
thread where people wonder why something that looks plausible is
disallowed. The only ones disallowed would then be cases that actually
were problematic instead of cases that got hit as a side effect of
simpified restrictions. It would be a lot simpler to point out to
someone how his particular code was problematic than to explain that
other code could be problematic and that's why his apparently fine code
was disallowed.
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>
>Oh. True. In explaining why restrictions are needed, I forgot (um, I
>mean oversimplified :-)) that some possible variants of the restrictions
>don't use ordering. Ordering just happens to be a relatively simple one
>to express in standard-speak. It isn't without its complications (not at
>all), but it can be simpler than writing precise conditions that
>guarantee a finite, unique result.
>
>One proposal that I've heard made, at least informally, is that the
>Fortran standard doesn't need to lay out the explicit conditions, but
>could instead just express it more generally as that the solution must
>be finite and unique (or other simillarly general terms). That is
>perhaps a bit radical in terms of language standard traditions, but it
>isn't necessarily any less precise and rigourous. It just avoids putting
>all of the math into the standard. I found the idea intriguing.
Precisely. That's what Algol 68 did, though in fairly mathematical
terms. It's rather sad that the obscurity of the notation used for
specifying that caused a reaction against semi-formal definitions,
and against Algol 68, because it got a lot of things right. As you
know, Fortran 90 array sections and assumed-shape arrays were lifted
staight from Algol 68.
Regards,
Nick Maclaren.
glen herrmannsfeldt
I didn't know that. Where did PL/I get its array operations from?
(Not quite as much as newer Fortran.)
I think that would have been before 1968, so maybe from Algol 60?
-- glen
nm...@cam.ac.uk
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>< That's what Algol 68 did, though in fairly mathematical
>< terms. It's rather sad that the obscurity of the notation used for
>< specifying that caused a reaction against semi-formal definitions,
>< and against Algol 68, because it got a lot of things right. As you
>< know, Fortran 90 array sections and assumed-shape arrays were lifted
>< staight from Algol 68.
>
>I didn't know that. Where did PL/I get its array operations from?
>(Not quite as much as newer Fortran.)
>
>I think that would have been before 1968, so maybe from Algol 60?
Very probably. The designers of PL/I included everything that they
thought was useful from COBOL, FORTRAN and ALGOL 60, and I suspect
APL :-)
Regards,
Nick Maclaren.
Gordon Sande
They forgot conditional expressions from Algol 60. I was at seminar
where McIlroy was asked and the reply was "We forgot to put them in"
or something to that effect. There was a long apology about how if
they had known that they really had 2 years rather than the original
requested (by IBM) 6 months the product would have been much different.
> Regards,
> Nick Maclaren.
nm...@cam.ac.uk
Gordon Sande <g.s...@worldnet.att.net> wrote:
>> Very probably. The designers of PL/I included everything that they
>> thought was useful from COBOL, FORTRAN and ALGOL 60, and I suspect
>> APL :-)
>
>They forgot conditional expressions from Algol 60. I was at seminar
>where McIlroy was asked and the reply was "We forgot to put them in"
>or something to that effect. There was a long apology about how if
>they had known that they really had 2 years rather than the original
>requested (by IBM) 6 months the product would have been much different.
I find it odd (and inconvenient) that they have got into Fortran
only by back doors.
Regards,
Nick Maclaren.
jfh
>
> >> Very probably. The designers of PL/I included everything that they
> >> thought was useful from COBOL, FORTRAN and ALGOL 60, and I suspect
> >> APL :-)
>
> >They forgot conditional expressions from Algol 60. I was at seminar
> >where McIlroy was asked and the reply was "We forgot to put them in"
> >or something to that effect. There was a long apology about how if
> >they had known that they really had 2 years rather than the original
> >requested (by IBM) 6 months the product would have been much different.
>
> I find it odd (and inconvenient) that they have got into Fortran
> only by back doors.
>
> Regards,
> Nick Maclaren.
Indeed. The nearest I know of to a Fortran conditional expression is
merge(a,b,c) where a and b are expressions of the same type and type
parameters, and c is logical, but it has three annoyances: (1) it's
illegal in an F95 initialization expression because c is neither
integer nor character (2) both a and b may be evaluated, rather than
the Algol 68 equivalent "if c then a else b fi", in which only the
relevant one of a and b is. That's annoying if b would be meaningless
when c is true or if a would be when c is false (3) if a and b are of
type character they must be the same length.
John Harper
Dick Hendrickson
called VECTRAN. Some other parts were lifted from what the herd
of (mostly Boston based) multi-processor companies that were
soldering together hundreds of discrete chips were doing.
Another significant driver was the UK company ICL and their
DAP machine. Those companies may have gotten their ideas
directly from Algol 68. But I am sure that the person who
wrote many of the internal X3J3 papers that led to the array
processing stuff wasn't driven by Algol 68.
Dick Hendrickson
>
> Regards,
> Nick Maclaren.
robin
Not APL, but the others, yes, and then some, as I mentioned.
robin
> Where did PL/I get its array operations from?
> (Not quite as much as newer Fortran.)
>
> I think that would have been before 1968, so maybe from Algol 60?
Dynamic arrays were from Algol 60 (but note that
dynamic arrays were already in GIP (1955)).
Algol 60 didn't have whole array operations.
These were not in any of Algol, FORTRAN and COBOL.
There were, however, languages such as GIP (1955)
on Pilot ACE and DEUCE where operations on dynamic
whole arrays and sections were expressed.
Many other things were new that were put in PL/I,
such as varying-length strings,
bit strings and bit string handling, generic functions
and subroutines, and the like.
robin
news:2009051017334316807-gsande@worldnetattnet...
> They forgot conditional expressions from Algol 60.
Thank goodness. Along with Jensen's device, etc.
> I was at seminar
> where McIlroy was asked and the reply was "We forgot to put them in"
> or something to that effect.
He was probably joking.
nm...@cam.ac.uk
jfh <john....@vuw.ac.nz> wrote:
>
>Indeed. The nearest I know of to a Fortran conditional expression is
>merge(a,b,c) where a and b are expressions of the same type and type
>parameters, and c is logical, but it has three annoyances: (1) it's
>illegal in an F95 initialization expression because c is neither
>integer nor character (2) both a and b may be evaluated, rather than
>the Algol 68 equivalent "if c then a else b fi", in which only the
>relevant one of a and b is. That's annoying if b would be meaningless
>when c is true or if a would be when c is false (3) if a and b are of
>type character they must be the same length.
Yes, with one niggle. The "only one is evaluated" rule doesn't make
any sense in a Fortran expression.
Regards,
Nick Maclaren.
nm...@cam.ac.uk
Dick Hendrickson <dick.hen...@att.net> wrote:
>> As you
>> know, Fortran 90 array sections and assumed-shape arrays were lifted
>> staight from Algol 68.
>>
>Well, no. They were almost lifted straight from an IBM language
>called VECTRAN. Some other parts were lifted from what the herd
>of (mostly Boston based) multi-processor companies that were
>soldering together hundreds of discrete chips were doing.
>Another significant driver was the UK company ICL and their
>DAP machine. Those companies may have gotten their ideas
>directly from Algol 68. But I am sure that the person who
>wrote many of the internal X3J3 papers that led to the array
>processing stuff wasn't driven by Algol 68.
Well, maybe. There was also one Algol 68 fanatic and one supporter
who were heavily involved, and I know that they were copying Algol 68.
That doesn't conflict with your statement, but does mean that my
original one should be corrected by removing the word 'straight', or
perhaps by changing it to 'partly'! I would have to read the Vectran
paper to see whether they acknowledge Algol 68 influence.
Regards,
Nick Maclaren.
Gordon Sande
> "Gordon Sande" <g.s...@worldnet.att.net> wrote in message
> news:2009051017334316807-gsande@worldnetattnet...
>
>> They forgot conditional expressions from Algol 60.
>
> Thank goodness. Along with Jensen's device, etc.
>
>> I was at seminar
>> where McIlroy was asked and the reply was "We forgot to put them in"
>> or something to that effect.
>
> He was probably joking.
In which case he deserves many awards for acting, as well as
improvisation for his ability to followup with a long explanation
on the flawed specification development process they were forced
to follow.