Description
The implementation of first the generic statistical functions in stdlib exposed the lack of a general array indexing infrastructure of Fortran. For example, in the experimental implementation of a generic mean() function one has to generate a separate function for each possible rank. It would be nice, if Fortran offered an infrastructure which makes the generation of this vast amount of routines unnecessary. Let's collect in this issue, what we would need for that:
I my opinion, we lack following features for the moment:
- Possibility for a function to return an array with a rank unknown at compile time (the array should not be necessary an allocatable one!)
- General indexing scheme, which allows accessing arrays / strides / slices in an array without the usual comma-separated index notation. (Funny enough, the Fortran 2018 C-interoperability makes that possible, but only in C! It would be nice, if he had similar tools in Fortran!)
As a proof of concept, let's require functionality which enables to write a function, which just wraps the sum() intrinsic (taken from #144).
module test
implicit none
contains
function sum_wrapper(array, dim) result(redarray)
real, dimension(..), intent(in) :: array
integer, intent(in) :: dim
! Dimension would be an array of "slice-types" allowing dynamic
! determination of the shape of the returned array
real, dimension(get_redarray_shape(array, dim)) :: redarray
redarray(get_redarray_shape(array, dim)) = sum(array, dim=dim)
end function sum_wrapper
pure function get_redarray_shape(array, dim) result(redshape)
real, dimension(..), intent(in) :: array
integer, intent(in) :: dim
type(slice), dimension(rank(array) - 1) :: redshape
integer :: ii
do ii = 1, dim - 1
! With the intrinsic function get_slices, we should get access to the
! slicing parameters of the array (similar, how you can do it in C since
! Fortran 2018)
redshape(ii) = get_slices(array, dim=ii)
end do
do ii = dim + 1, rank(array)
redshape(ii - 1) = get_slices(array, dim=ii)
end do
end function get_redarray_shape
end module test
Having functionality along those lines (eventually combined with the one described in #144) would enable to write rank-agnostic general functions, on par with the intrinsic sum() and product() functions.