[J3] Remove requirement that passed-object dummy argument is required to be scalar?

[Van Snyder]

On Thu, 2021-12-09 at 23:15 +0000, Brad Richardson via J3 wrote:
> How would the procedure be called with a scalar then? I.e.
> 
> type(list_t) :: my_list
> 
> ...
> 
> if (my_list%check_list()) then
>  ...

If it's called with a scalar, e.g. "call list%check_list," then the
check_list procedure can't access the previous and next items because
it doesn't have access to the array.

> I think to remove the constraint would require new features to deal
> with all these kinds of cases.

I'm not sure what other cases would need attention. I didn't read the
whole standard again, but in my superficial study, I couldn't find
anywhere that "scalar" vs, "array" for the passed-object dummy argument
would make a difference -- except in C760.

> On Thu, 2021-12-09 at 15:06 -0800, Van Snyder via J3 wrote:
> Is there a technical reason that the passed-object dummy argument is
> required to be a scalar?
> 
> In an old code, have a module with a "list" type that manages double-
> linked lists, where the links are subscripts in an array of "list"
> type. The current version of the "list" type has a single additional
> "item" component of type integer that is a subscript into another
> array. I'd like to extend the list type to incorporate a component of
> that other type (or its its components), rather than needing two
> types, and needing to connect the objects using subscripts. This
> would be trivial using a parameterized module instead of type
> extension.
> 
> One of the module procedures checks that the list is consistent, by
> verifying that the "next" component of the previous list item is in
> fact the current item, and the same for the next one.
> 
> If something goes wrong, it calls another procedure to dump the list
> item -- along with its predecessor and successor. 
> 
> I can't make those procedures  type-bound procedures because the
> passed-object dummy argument is required to be a scalar.
> 
> Therefore, I can't inherit those procedures into extension types, and
> override them.
> 
> A work-around kludge is to make "list" have a single array component
> that is the real list. This adds another level of component selection
> in every reference.
> 
> Another kludge is to use pointers to scalar "list" objects, instead
> of subscripts, but that's an invitation to memory leaks because we
> don't have reference-counted targets or intrinsic garbage collection.
> 
> If there is no compelling reason that the passed-object dummy
> argument is required to be a scalar, can that clause of C760 be
> removed?
> 
>   logical function Check_List ( List, Message ) result ( Wrong )
>   ! Verify that each list item's predecessor's "next" component indexes
>   ! that item, and the same for its successor mutatis mutandis.
>     class(list_t), intent(in) :: List(:)
>     character(*), intent(in), optional :: Message
>     integer :: I, N, P
>     do i = 1, size(list)
>       p = list(i)%prev
>       n = list(i)%next
>       wrong = .false.
>       if ( p /= 0 ) wrong = list(p)%next /= i
>       if ( n /= 0 ) wrong = wrong .or. list(n)%prev /= i
>       if ( wrong ) then
>         if ( present(message) ) write ( unit, '(a)' ) trim(message)
>         call dump_list_item ( list, i, prevNext=1 )
>       end if
>     end do
>   end function Check_List
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20211209/104131ad/attachment-0001.htm>