For the SIN function it's rather awkward to write a generic version
because even after argument reduction the result is obtained by
evaluating a minmax polynomial (actually for SIN perhaps a minmax
polynomial for sin(x)/x) which has different orders for different KINDs.
This means that you would almost have to develop and test different
code for each KIND.
For procedures where the same code works for different KINDs, you can
write a template procedure where the KIND is called something like
'wp' (for Working Precision) and INCLUDE this procedure in various
MODULEs, and USEing those MODULEs in others, perhaps with rename
clauses if you want specific names to be available for the different
versions. I have an example of this in
http://home.comcast.net/~kmbtib/Fortran_stuff/GENERIC_BLAS.ZIP .
This style of template programming will work across user-defined
types or across INTEGER KINDs or across LOGICAL KINDs or across
REAL KINDs, but not on a combination that mixes the above sets.
For this kind of genericity (as for order statistics just to give
one example) we can still achieve template programming but it's
necessary to use implicit typing. The template type now takes
the place of the 'wp' KIND and this means we are limited to no
more than 26 independent template types of this ilk. I have posted
an example at
http://home.comcast.net/~kmbtib/Fortran_stuff/funr1.ZIP .
This issue about not knowing in advance how many KIND types will
be available is insoluble, AFAIK. What I do in my GENERIC_BLAS
example is to write out different versions for the different
numbers of KIND types.
