Is this standard f90?

[Jason]

I just started on learning Fortran 90 and need your opinions on the
following code:

!!!!!!Start
module stuff

type t1
integer, dimension(:), allocatable::a
integer, dimension(:), allocatable::b
end type t1

type t2
type(t1), dimension(:), allocatable:: t1_a
integer, dimension(:), allocatable:: c
end type t2
end module stuff

program test

use stuff

implicit none

type(t2):: my_var

if(.not. allocated(my_var%t1_a)) allocate(my_var%t1_a(5))
if(.not. allocated(my_var%c)) allocate(my_var%c(5))

if(allocated(my_var%t1_a(1)%a)) then
write(*,*) "Size of my_var%t1_a(1)%a = ", size(my_var%t1_a(1)%a)
! deallocate(my_var%t1_a(1)%a)
end if

end program test

!!!!!!End

I tried my code on Visual Fortran 6.6, the f90 compiler that comes
with TrueUnix 64 and Irix 6.5. The code compiled and run on Visual
Fortran but not on TrueUnix 64 and Irix 6.5. On TrueUnix64 and Irisx
the compiler complain about array must have explict size, or use
pointers. But from I have read so far, my code has not violated any
Fortran standard.

As for VF6.6, even though I have not allocated any memory to
my_var%t1_a(1)%a, it's allocated with size of 0? If I try to
deallocate the memeory, there's an error. Why?

I can use pointers, but then I cannot use "intent(in)" declaration
with pointers. So I need your opinion on whether my code is standard
or not.

[Arjen Markus]

Post by Jason
I just started on learning Fortran 90 and need your opinions on the
!!!!!!Start
module stuff
type t1
integer, dimension(:), allocatable::a
integer, dimension(:), allocatable::b
end type t1
type t2
type(t1), dimension(:), allocatable:: t1_a
integer, dimension(:), allocatable:: c
end type t2
end module stuff
I can use pointers, but then I cannot use "intent(in)" declaration
with pointers. So I need your opinion on whether my code is standard
or not.

Within derived types you can not use allocatable arrays, unless
a well-defined extension to the language is available (TR....).

This _will_ be part of the next standard.

intent(in) with pointers is a bit problematic because there is
no way to say:

the object pointed to can not change its values

or

the pointer can not be made to point to another object

There is some convention for it to mean the first though, IIRC

Regards,

Arjen

[Jason]

Post by Arjen Markus

Post by Jason
I just started on learning Fortran 90 and need your opinions on the
!!!!!!Start
module stuff
type t1
integer, dimension(:), allocatable::a
integer, dimension(:), allocatable::b
end type t1
type t2
type(t1), dimension(:), allocatable:: t1_a
integer, dimension(:), allocatable:: c
end type t2
end module stuff
I can use pointers, but then I cannot use "intent(in)" declaration
with pointers. So I need your opinion on whether my code is standard
or not.

Within derived types you can not use allocatable arrays, unless
a well-defined extension to the language is available (TR....).
This _will_ be part of the next standard.
intent(in) with pointers is a bit problematic because there is
the object pointed to can not change its values
or
the pointer can not be made to point to another object
There is some convention for it to mean the first though, IIRC
Regards,
Arjen

Thanks for your information, Arjen. It turns out that Visual Fortran
6.6b extends the "allocatable" syntax to derived-type.

[Richard Maine]

Post by Jason
I tried my code on Visual Fortran 6.6, the f90 compiler that comes
with TrueUnix 64 and Irix 6.5....
But from I have read so far, my code has not violated any
Fortran standard....
I can use pointers, but then I cannot use "intent(in)" declaration
with pointers. So I need your opinion on whether my code is standard
or not.

Well, your code violates some Fortran standards, but not others.
Your compilers may well be implementing different levels of the
standard.

Allocatable components are not allowed in f90 or in the base f95.
They are added by a TR that is implemented in some f95 compilers
(and is part of the base standard for the upcoming f2003).

Intent specification for pointers is not allowed in either f90 or f95.
It is allowed in f2003. It might possibly be implemented as an
extension in some f90/f95 compilers, but is not in any approved
standard (f2003 not yet being approved, though hopefully this
year).

As Arjen mentioned, there are issues with defining exactly what
intent specification means for pointers. I forget which
definition is in the latest f2003 draft and I don't have time
to look it up right now - have to run to a meeting.

[James Giles]

Richard Maine wrote:
...

Post by Richard Maine
As Arjen mentioned, there are issues with defining exactly what
intent specification means for pointers. I forget which
definition is in the latest f2003 draft and I don't have time
to look it up right now - have to run to a meeting.

For POINTER dummy arguments, INTENT(IN) means
that the POINTER may not be defined (redefined, become
undefined, blah). The TARGET of that dummy argument
may be defined (etc.).

For POINTER dummy arguments, INTENT(OUT) means
that no target may be referenced through the POINTER
until it is explicitly defined within the procedure (or
something the procedure calls).

The first of these is unfortunate since I more often need the
(still unavailable) means to declare that a pointer is allowed
to change, but no target associated with it may be changed.
But, the existing rule is necessary in order to be consistent
with the rule for derived type dummy arguments that contain
pointer components. :(

[Richard Maine]

Post by James Giles
...

Post by Richard Maine
As Arjen mentioned, there are issues with defining exactly what
intent specification means for pointers. I forget which
definition is in the latest f2003 draft and I don't have time
to look it up right now - have to run to a meeting.

For POINTER dummy arguments, INTENT(IN) means
that the POINTER may not be defined (redefined, become
undefined, blah). The TARGET of that dummy argument
may be defined (etc.).
For POINTER dummy arguments, INTENT(OUT) means
that no target may be referenced through the POINTER
until it is explicitly defined within the procedure (or
something the procedure calls).

Really? That seems inconsistent. Intent(in) refers to the
pointer association status, but intent(out) refers to the target?
Let me check now that I'm back...(looking)...

I agree that's what the FCD says about INTENT(IN), but I disagree
that this is what it says about INTENT(OUT). Either that or I
am misreading what you mean to say. From [81:22-24] of the FCD

"The INTENT(OUT) attribute for a pointer dummy argument specifies
that on invocation of the procedure the pointer association
status of the dummy argument becomes undefined."

So, for intent(out), you need to define the pointer association
status before you "do anything" with the argument. You can't just
go define the value of the target, because there isn't a target.

Whether one thinks these the "right" definitions or not, at least
they are consistent with each other - both are about the pointer
association status isntead of about the value of th etarget.

[James Giles]

Richard Maine wrote:
...

Post by Richard Maine

Post by James Giles
For POINTER dummy arguments, INTENT(OUT) means
that no target may be referenced through the POINTER
until it is explicitly defined within the procedure (or
something the procedure calls).

Really? That seems inconsistent. Intent(in) refers to the
pointer association status, but intent(out) refers to the target?
Let me check now that I'm back...(looking)...
I agree that's what the FCD says about INTENT(IN), but I disagree
that this is what it says about INTENT(OUT). Either that or I
am misreading what you mean to say. From [81:22-24] of the FCD
"The INTENT(OUT) attribute for a pointer dummy argument specifies
that on invocation of the procedure the pointer association
status of the dummy argument becomes undefined."

So, you can't reference a target through it. That's what I said.
Maybe my statement was not complete: you also can't test the
pointer's association status or use it on the right of a pointer
assignment, but you certainly can get to any targets through it.

[Richard Maine]

Post by James Giles
...

Post by Richard Maine
I agree that's what the FCD says about INTENT(IN), but I disagree
that this is what it says about INTENT(OUT). Either that or I
am misreading what you mean to say....

So, you can't reference a target through it. That's what I said.
Maybe my statement was not complete: you also can't test the
pointer's association status or use it on the right of a pointer
assignment, but you certainly can get to any targets through it.

Ok. Then I misread what you intended to say. That's not quite
what your words said to me, but no need to have a meta-argument about
that as long as we agree about what the draft standard says, which we
appear to do. I don't think I'll bother to try to explain how I
(mis)read your words.