Give a Yiti

I must say that the method _base_d on implicit statements is very clever, and, _base_d only on fortran statements, allows to minimize the code duplication. But is it possible to declare something like this : module data_mod   type MYDATA     character(len=20) :: string   end type MYDATA    implicit type(MYDATA) (Q)    include 'test3_template.i90' end module data_mod I don't think so, which shows that the method cannot be extended to abstract data types. Yes, it is possible to do something like that. The only problem with the above is one of ordering. Implicit statements have to come quite early in a scoping unit, before pretty much anything other than USE statements. I forget whether it would be ok to just swap the order or whether a different ordering constraint prevents that. If that doesn't work, defining the derived type in a separate module, which you USE here, would work. Derived types are allowed in implicit statements, I'm sure. However, I can't really recommend that approach. The well-known error-proneness of implicit typing is greatly magnified in the presence of derived types, modules, and host association.

I must say that the method _base_d on implicit statements is very clever, and, _base_d only on fortran statements, allows to minimize the code duplication. But is it possible to declare something like this : module data_mod   type MYDATA     character(len=20) :: string   end type MYDATA    implicit type(MYDATA) (Q)    include 'test3_template.i90' end module data_mod I don't think so, which shows that the method cannot be extended to abstract data types. But funny though. The method is indeed clever.  Wish I had thought of it myself, but someone else suggested it in clf. As Richard pointed out of course you can do this: C:gfortranclftemplate_wartype test3_template.i90   private   public readfile_data   interface readfile_data     module procedure READFILE_DATA_NAME   end interface readfile_data   contains     subroutine READFILE_DATA_NAME(current_data_line,Qmyvalue,status)       character(len=*), intent(in) :: current_data_line       intent (out) :: Qmyvalue       integer, intent(out) :: status       status = 0       read(current_data_line, *, err=100 , end=100) Qmyvalue       return 100   continue       status = 1     end subroutine READFILE_DATA_NAME C:gfortranclftemplate_wartype test7.f90 module data_mod    implicit none    type MYDATA       character(len=20) string    end type MYDATA end module data_mod module logical_mod    implicit logical (Q) include 'test3_template.i90' end module logical_mod module integer_mod    implicit integer (Q) include 'test3_template.i90' end module integer_mod module MYDATA_mod    use data_mod    implicit type(MYDATA) (Q) include 'test3_template.i90' end module MYDATA_mod module m_moduletest3    use logical_mod    use integer_mod    use MYDATA_mod end module m_moduletest3 program test3   use data_mod   use m_moduletest3   character (len=200) :: current_data_line   integer :: myintvalue1   logical :: mylogicalvalue1   type(MYDATA) :: myMYDATAvalue1   integer :: status   current_data_line = 1   call readfile_data(current_data_line, myintvalue1, status)   write(*, *) status: , status   write(*, *) Integer : , myintvalue1   current_data_line = .true.   call readfile_data(current_data_line, mylogicalvalue1, status )   write(*, *) status: , status   write(*, *) Logical : , mylogicalvalue1   current_data_line = 'Hello from James'   call readfile_data(current_data_line, myMYDATAvalue1, status )   write(*, *) status: , status   write(*, *) MYDATA : , myMYDATAvalue1 end program test3 C:gfortranclftemplate_warc:gfortranwin64binx86_64-pc-mingw32-gfortr an te st7.f90 -otest7 C:gfortranclftemplate_wartest7  status:           0  Integer :            1  status:           0  Logical :  T  status:           0  MYDATA : Hello from James

However, I can't really recommend that approach. The well-known error-proneness of implicit typing is greatly magnified in the presence of derived types, modules, and host association. This _object_ion shows that you have never done template programming in C++.  It turns out to be so gawdawful that the normal way to develop template code is to start with a non-template class and methods, get that working OK, then convert to templates.  Working in an analogous fashion in Fortran, the non-template version would have IMPLICIT NONE in force and only when it's working OK would implicit typing be introduced.  Besides IMPLICIT NONE won't help with host association until the committee gives us some way to restrict host association. The really ugly part is: what are you supposed to do when you need more than 26 template types?  Maybe a Chinese Fortran compiler would become popular at this point.  Code with 26 template types would be harder to read than Chinese, for sure.

The really ugly part is: what are you supposed to do when you need more than 26 template types?  Maybe a Chinese Fortran compiler would become popular at this point.  Code with 26 template types would be harder to read than Chinese, for sure. Java has all the alphabetic unicode characters legal for variable names.  Confusingly, there are some that look exactly like normal letters but are different places in the unicode character set. I would probably keep one letter each for integer and real.

(snip) The really ugly part is: what are you supposed to do when you need more than 26 template types?  Maybe a Chinese Fortran compiler would become popular at this point.  Code with 26 template types would be harder to read than Chinese, for sure. Java has all the alphabetic unicode characters legal for variable names.  Confusingly, there are some that look exactly like normal letters but are different places in the unicode character set. That could take obfuscated code to a whole new level.

You forgot callbacks : ! Fortran 95 implementation of the quicksort algorithm.  This ! subroutine does not directly touch the array it sorts; rather it ! relies on the two callbacks compare and exchange for that.  Code ! inspired by R. Sedgewick, Algorithms in C and correspondence with ! Glen Herrmannsfeldt. subroutine quicksort(n, compare, exchange)   implicit none   integer, intent(in) :: n ! the length of the implied array Callbacks are a powerful way of uncoupling the sorting algorithm from the type of data to sort, that is true. That moves the data type from the sorting method to the client code, where you have to implement a quicksort method which is _base_d on a particular type of data and pass the type-specific compare method to the generic quicksort method. The final implementation with callbacks is a move of the code duplication from the sorting algorithm to the client of the sorting algorithm, because, in the end, you need a method to sort all types of arrays of data : there is a benefit to use the quicksort algorithm the way you showed it, but the problem appears in the client of the quicksort. My point of view is that callbacks cannot be used to manage templates, but are a powerful way to configure a method for a particular processing. In the sorting example, one can imagine several compare methods to sort a list of strings : - compare strings so that the sort is done in increasing order, - compare strings so that the sort is done in decreasing order, - compare strings so that the strings are converted to integers and that the sort is done in increasing order, - compare strings so that the strings are converted to integers and that the sort is done in decreasing order, - compare strings so that the strings are converted to real and that the sort is done in increasing order, - compare strings so that the strings are converted to real and that the sort is done in decreasing order, etc... Regards, Michaël