Anything wrong with this code?

Help
16

Not in the current standard. See this thread re: some extension in the next revision, Fortran 2023.

Ultimately, Fortran coders will realize the situations that require the use of SELECT TYPE in codes often imply the need of generics more than OO. That also may mean the development of the application(s) in question, especially in the scientific domains with the need to describe a lot of physical phenomena and natural behavior, do require a lot of thought and analyses and even premeditation that needs to be followed by careful design in pseudocode prior to commencement of the programming.

Toward the case in the original post, a consideration can be the use of some sorting of hashing toward the comparer function and having a deferred procedure only for the subclasses to dispatch suitable hashes that the abstract “base” class utilizes: this can help simplify the subclassed implementations and avoid the SELECT TYPE.

   ..
   type, abstract :: bst_base_node_type
      class(bst_base_node_type), allocatable :: left
      class(bst_base_node_type), allocatable :: right
   contains
      procedure(Ihash), deferred :: hash
      procedure(print_interface), deferred :: print
      procedure :: compare => base_node_compare
   end type bst_base_node_type

   abstract interface
      elemental function Ihash( node ) result(hash)
      ! return a hash for the instance
         import :: bst_base_node_type
         class(bst_base_node_type), intent(in) :: node
         integer(kind=K) :: hash ! where K is a suitable kind, 64-bit integer?
      end function Ihash
      ..
   ..
contains
   elemental function base_node_compare( node1, node2 ) result(r)
      class(bst_base_node_type), intent(in) :: node1, node2
      integer :: r
      r = 2
      if ( same_type_as( node1, node2 ) ) then
         associate ( lh => node1%hash(), rh => node2%hash() ) 
            if ( lh < rh ) then
               r = -1
            else if ( lh > rh ) then
               r = 1
            else
               r = 0
            end if
         end associate
      end if
   end function
   ..

Separately, note the “school of thought” currently is to not employ OO as a substitute for Generics. Eventually as Generics makes into the language, conceivably one can apply Generics on top of certain concrete class hierarchy(ies) toward certain needs. But generally the language extension appears to take the position to not support an enmeshing of the two paradigms, at least in the first revision.