> The actual function characteristics are defined in your module Q_FUNC,
>   FUNCTION Q(Z)
>   ! same error whether using the commented-out lines or the two following
>   ! them, so the problem is not the fancy dimension stuff
>   !REAL(SP), DIMENSION(:), INTENT(IN)  ::  Z
>   !REAL(SP), DIMENSION(SIZE(Z))  ::  Q
>   REAL(SP)  ::  Z
>   REAL(SP)  ::  Q
>
> The dummy function charactersitics are in Numerical Recipes' functions.
> This is the one in qtrap, for example.
>                 FUNCTION func(x)
>                 USE nrtype
>                 REAL(SP), DIMENSION(:), INTENT(IN) :: x
>                 REAL(SP), DIMENSION(size(x)) :: func
>                 END FUNCTION func
> These must match.
>
> First, a scalar actual does not match for an array dummy. It was not
> supposed to, even in FORTRAN 77. For example, in FORTRAN 77 it was
> written in 15.9.3.3 of the standard, "A dummy argument that is an
> array may be associated with an actual argument that is an array,
> array element, or array element substring". No mention of variables.
> I think this explains
> >> %F90-E-ERROR, The shape matching rules of actual arguments and dummy
> >> arguments have been violated.   [Q]

Right.  As I mentioned in another post, I correctly get an error that
they don't match.  Sorry for the confusion.

> Second, I don't readily see what's wrong with the commented out lines
> in your function Q above,

Yes, that's the real problem.

> but one thing that can happen is that if you
> compile your library routines with one value for SP (say, for single
> precision), and compile your program separately with another value
> for SP (for double precision, for example), that certainly causes a
> difference in the characteristics of the associated actual and dummy
> functions.

SP is just what is returned by SELECTED_REAL_KIND.  This value is
calculated when compiling the NUMERICAL RECIPES routines, and is just
USEd by my code.

> A third point I'd like to bring up, which is a bit off-topic but is
> really what I wanted to say in this post is that you say:
>
> >>seems to me that a MODULE used by just one program is a bit of overkill
> >>(which is why I want to include it in the same file, to make it clear
> >>that it is just a one-off thing for the function I want to integrate).)

[big snip]

> Books should at least mention that the MODULE can be used that way.
> A MODULE for a single program is not overkill, it is only natural.
> It's just that it shouldn't be confused with the use of MODULEs to
> package library routines.

You're right, of course.  However, in my case an internal procedure
would actually be more natural (but it's non-standard, so I don't use
it; I don't even know if any compiler will accept it in this case).  The
function I want to integrate actually depends on three variables, one of
which is the integration variable and two other variables.  With an
internal procedure, these other two variables would be accessible via
host association.  In my case, I have to declare them either in the
module containing the function to be integrated, where they really don't
belong, and access them via USE in the main program, or put them in a
second module and USE that both in the main program and in the module
containing the function to be integrated.