Richard Maine wrote:
> 
> Alvaro Agustin Fernandez writes:
>  > Malcolm Cohen wrote:
>  > 
>  > > >subroutine zero (number, doit)
>  > > >  integer, intent(out) :: number
>  > > >  logical, intent(in) :: doit
>  > > >
>  > > >  if (doit) then
>  > > >     number = 0
>  > > >  end if
>  > > >end subroutine zero
>  > > >
>  > > >The problem is with 'number'. Is intent(out) correct, because it's never
> 
>  > No INTENT is the same as INTENT(INOUT), though, and it also documents that the
>  > arg. is part of the call list.  Is  there any reason not to include it, then?
>  > (Not being pedantic - actually curious...)
> 
> No they are not the same, although they are similar.  Indeed, this
> example can be used to illustrate the difference.  With INTENT(INOUT),
> the actual argument is required to be definable, even if you don't
> happen to define it for the particulat call.  Thus, for example, it is
> illegal to call the above subroutine with
> 
>   call zero(123, .false.)
> 
> and this call would still be illegal if you changed the INTENT of
> number to INOUT.  However, if you omit the INTENT, then the actual
> argument is only required to be definable if the call actually does
> define the dummy.  Thus, if the INTENT for number was omitted, it
> would be legal to do
> 
>   call zero(123, .false.)
> 
> but it would still be illegal (as it is for all possible INTENTs) to do
> 
>   call zero(123, .true.)
> 
> I advise against omitted INTENT in general.  I consider it confusing
> and error prone, and it reduces the chances for the compiler catching
> problems.  But exceptions exist.  If you have existing code
> that needs it (it was, after all, the only option in f77) then it may
> be better to keep the code as is than to rewrite it.  And I might even
> have on rare occasion written new code that needs it, but I'd say this
> should at least be rare.

Shouldn't a INTENT(in.or.out) be introduced?  Even if it won't do
anything useful to compilers, it would at least be more informative than
there is no INTENT at all.

The "exceptions" to the three standard INTENTs are not rare in parallel
programs where the behavior of a procedure sometime depends on which
processor the software segment sits.  For example, for message-passing,
one may have

  type mesg; integer :: i; end type mesg
  type(mesg),allocatable :: sendbuf(:), recvbuf(:)

  n=...
  allocate(sendbuf(n))
  do i=1,n
    sendbuf(i)=mesg(i)
  end do

  if(myPE()==root) then
    allocate(recvbuf(n*nPE))
    call mesg_gather(sendbuf,recvbuf,root,comm)
    call mesg_output(recvbuf)
    deallocate(recvbuf)
  else
    call mesg_gather(sendbuf,(/mesg(123)/),root,comm)
  endif

  deallocate(sendbuf)

where mesg_gather() should be defined as

  subroutine mesg_gather(sendbuf,recvbuf,root,comm)
  type(mesg),intent(in) :: sendbuf(:)
  type(mesg) :: recvbuf(:)
  ...

The second argument in mesg_gather(), recvbuf, is "significant only
at root" for output, similar to the argument number in subroutine
zero().  Similar cases can be easily picked up from the MPI standard
document.  These cases represent basic algorithm patterns under the
Single-Program-Multiple-Data paradigm. 

I am sorry I have to skip many details in the example above.  I hope
there are enough details to make a case.

Jing

> 
> -- 
> Richard Maine
> [log in to unmask]
> 
-- 
________________________________ _-__-_-_ _-___---
Jing Guo, [log in to unmask], (301)614-6172(o), (301)614-6297(fx)
Data Assimilation Office, Code 910.3, NASA/GSFC, Greenbelt, MD 20771


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%