I'd originally intended to overload the concatenation operator for ordered data types. This was to be done by creating a deffered type-bound procedure in the abstract ordered type, like below:

type, extends(countable), abstract, public :: ordered
contains
  ! ...
  procedure(concat_func), private, deferred :: concat
  generic :: operator(//) => concat
end type ordered

abstract interface
  function concat_func(lhs, rhs)
    import ordered
    class(ordered), intent(in) :: lhs, rhs
    class(ordered), allocatable :: concat_func
  end function concat_func
end interface

One consequence is that this means that the returned, concatenated, object must be an allocatable abstract type. In some cases that can be useful, but in others it's a pain because it would require type-guards to assign it to a variable of the actual type.

Another problem is the question of the ordering of the concatenation. My preference would be to order it such that using the pop() method to iterate through the returned object would function as though pop() had been used to iterate through the lhs object and then to iterate through the rhs object. However, doing this requires knowledge of the internal structure of the derived type, which is not available if the interface makes the object class(ordered). Furthermore, the concatenation can be performed much more efficiently if you act on the internal structure of the derived type directly, rather than just accessing it through the (rather few) methods available for class(ordered) objects.

One possibility would be to remove the method definition from ordered and place separate definitions
in each concrete derived type. This, of course, would mean that it can't be used in a polymorphic manner. Another possibility would be to keep the definition in the ordered type and use type-guards in each implementation. This would potentially be quite time consuming.

Thoughts?

I've put a great deal of thought into how to arrange the inheritance structures so as to get the most out of polymorphism. This is hindered somewhat by the fact that Fortran doesn't have a concept of interfaces like that of, say, Java. These are useful because they allow something along the lines of multiple inheritance and a greater degree of polymorphism. In any case, the inheritance structure I've come up with can be found in the wiki. If anyone has any suggestions on how to improve it, that would be great.

Hi Chris,

great project, my best compliments!

I would like to contribute if you like. In the past I have developed a generic container (based on an unlimited polymorphic class) with an octree structure (it was an hash table with single linked list for resolving keys conflicts on the single slot). I would like to contribute to your FIAT working on trees, how can I do?

Do you have some contributing guidelines?
Do you have some references for the trees you want to implement?
Do you have a preferred collaborative model (e.g. fork/pull-request)?

In my modest opinion, one of the worst lack of Fortran is the absence of generic containers, your FIAT is very appreciated.

My best regards.

Hi @cmacmackin ,

I have restarted to study FIAT with hope to contribute to it. I am now going to develop an hash-table with the hope to merge into FIAT.

I am almost sure I have asked this already, but I do not remember your answer... sorry.

For your abstract container you encode data by transfer built-in, e.g.

  type, public, abstract ::   container
    private
    integer(i1), dimension(:), allocatable :: storage  !! Variable in which to place data contents
    logical ::  filled = .false. !! `.true.` if container is set, `.false.` otherwise
  contains
    private
    procedure(guard), deferred :: typeguard
   ...
  end type container

I also used transfer-trick for generic list before class(*) becomes available in my main-stream compiler at that time. Now, I am wondering which are the advantages to prefer transfer-trick over the unlimited polymorphic data. For example I like to have the contained data defined as a pointer in order to avoid copy-in-copy-out every-time I manage the data (that in my application case could be large, order of 100MB). Moreover, you already use the select type cluttering-syntax for the typeguard method, thus the main cons of class(*) is already accomplished.

Currently, I am playing with something like

  type, public, abstract ::   container
    private
    class(*), pointer :: storage  !! Variable in which to place data contents
    logical ::  filled = .false. !! `.true.` if container is set, `.false.` otherwise
  contains
    private
    procedure(guard), deferred :: typeguard
    procedure(associate_to_contents_interface), deferred :: associate_to_contents
   ...
  end type container

where the associate_to_contents is similar to your typeguard, but performs only a pointer association.

I would like to know your opinions, in particular what you think are the main pros of transfer-trick over class(*).

Cheers.