Implement true arrays of fortran pointers

[rweed]

I'm writing some C-interop code that interfaces with C code that returns arrays of pointers to structures. Trying to unwind the multiple indirection (pointers to pointer to pointers) and load them into arrays of derived types containing pointers is to mind mind very clunky and forces you to use derived type component access syntax just to get to the pointer. I would like to propose the following:
Borrowing syntax from co-arrays, let a set of braces (AKA curly brackets) signal an array of Fortran pointers.
Example
Real, Pointer :: aptr(:) {10}
or
Type(Cstruct), Pointer :: astruct {:}

etc.

Extensions would also be required to ALLOCATE and C_F_POINTER but I not certain what is the best syntax for those yet so any suggestions would be welcome. I think something like this would be useful in place of trying to use arrays of Type(C_PTR)s (which is legal) instead of actual Fortran pointers. Just thought I would throw this out to see if anyone else thinks this has merit. I'm sure there are a lot of gotcha's I'm not seeing.

[septcolor]

I would also like to have some more "direct" method for holding or representing an array of pointers and an array of polymorphic variables (rather than wrapping them in a different derived type for every such case). To do so, in addition to literals like above, I wonder it may be useful to consider a builtin container type like

list(real) :: xs                          !! a list of primitive values
list(real, pointer) :: ps            !! a list of pointers
list(foo_t, allocatable) :: foos   !! a list of allocatable class variables

that supports

xs% append( y )
ps% reserve( 10 )
ps( 5 ) => q
foos% reserve( 10 )
allocate( foo_child_t :: foos( 5 ) )

(just a rough sketch but close to what I would like to have). Here I think having the attributes like "pointer" or "allocatable" to be part of list is crucial (apart from specific syntax), such that one can distinguish whether the components have such attribute when passed to different routines. I am still not sure whether this kind thing can play well with generics, but I guess it is at least closer to what std::vector<T*> in C++ is doing. Also, I think that the very reason for "why Fortran is considered weak for unstructured data" (discussed in some forum thread) is deeply related to this inconvenience / awkwardness of handling such "non-rectangular" data.

[difference-scheme]

I would also like to have some more "direct" method for holding or representing an array of pointers and an array of polymorphic variables (rather than wrapping them in a different derived type for every such case).

The lack of a direct possibility to declare arrays of pointers, and especially arrays of polymorphic variables, is one of the biggest deficiencies of the present language. I have myself come to the conclusion that the latter is even worse than the lack of true generics.

Arrays of polymorphic variables are needed everywhere in OO programming, and having to circumvent this fundamental flaw over and over again, by using design patterns that make use of derived type wrappers, becomes super-annoying, super quickly.

This is actually quite embarrassing for a language like Fortran, whose main strength is arguably the handling of arrays. Yet, when it comes to arrays of polymorphic variables, even Java beats Fortran. This needs to be fixed as soon as possible.

[septcolor]

The lack of a direct possibility to declare arrays of pointers, and especially arrays of polymorphic variables, is one of the biggest deficiencies of the present language.

I feel the same here... Even for a code pattern that can be easily expressed in other languages, I need to write much more codes to achieve the same goal, or just give up because the code becomes too ugly / unreadable. Many books about "algorithms" now use Python or C++, and never Fortran, which (I think) originates partly from this deficiency.

I know there are strong opinions in the Fortran community (even for the committee people) that OO is not suited for numerical computing (e.g. for efficiency reasons, or too tight coupling between data and methods). But IMO the problem is the weakness of object handling in general. I think the object-based approach is quite useful for controlling higher-level parts of the code, while lower-level routines can be written in a more "direct" fashion (to keep maximum efficiency).

IMO the evolution of object-related capability in Fortran stopped at F2003 (about 20 years ago), and there is huge gaps from other languages already. Because of this, I often feel it is more effective to use other languages for higher-level parts (to manage program flows / data handling / IO), while using Fortran only for lower-level "engine" parts (particularly when multi-dimensional arrays are important).

[difference-scheme]

I know there are strong opinions in the Fortran community (even for the committee people) that OO is not suited for numerical computing (e.g. for efficiency reasons, or too tight coupling between data and methods).

This is an uninformed myth, and nothing could be further from the truth than this (with the exception of Damian Rouson, whose research on the subject is well known, there are hardly any OO experts in the Fortran committees, and this shows). OO, if done right, decouples code without any loss in efficiency. I cannot go into details here, given the limited space. But this is what OO does, if it's done right.

I think the object-based approach is quite useful for controlling higher-level parts of the code, while lower-level routines can be written in a more "direct" fashion (to keep maximum efficiency).

You can use OO consistently in your lower level code as well, if you obey a few performance-related rules (like preferring classes of arrays instead of arrays of classes for these low-level code parts, etc.).

Because of this, I often feel it is more effective to use other languages for higher-level parts (to manage program flows / data handling / IO), while using Fortran only for lower-level "engine" parts (particularly when multi-dimensional arrays are important).

Personally, I think that Fortran's present OO capabilities aren't necessarily as bad as to force one into mixed programming. In fact, Fortran's support of the combination of OOP and multi-dimensional, built-in arrays is Fortran's greatest strength, as it is a combination that is unavailable in other "close to the metal" languages. Hence, the above flaw is double annoying, because it shows that the language is inconsistent in what it offers. What Fortran OO really lacks to live up to its true (huge) potential are:

1. Arrays of pointers and polymorphic objects (as mentioned above).
2. Multiple interface inheritance based on traits/polymorphic interfaces.
3. The possibility to declare immutable variables (especially immutable references).

Out of these, only the second item is really OO specific (see pull request #143 for a proposal to remedy this).