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]

Second, I don't readily see what's wrong with the commented out lines
in your function Q above, 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.
-----
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).)

This "a MODULE used by just one program is a bit of overkill" is an
impression shared by many who migrated to Fortran 90 from FORTRAN 77,
in my experience. I think it is an unfortunate misunderstanding brought
by the way Fortran 90 books introduce modules. Fortran MODULE serve
several different purposes; one is to package library routines shared
among programs. Books explaining modules in any detail explain this use.
Such modules have the "PRIVATE" statement to make everything within
the module default to private, and the USE statements accessing the
module usually specify the ONLY clause.

Another common use for MODULE is the simpler MODULE; the MODULE used
by a single program. This MODULE is part of the application you're
writing, and not of the library. It is only USEd by the main program,
and all subroutines you write goes into this module. This is necessary
because most of the good things added in Fortran 90 requires explicit
interfaces. Think of this module as an extension of the main program.
The default "PUBLIC" accessibility is OK because the module is part
of your own implementation and you're supposed to know everything
inside this module. The USE statement to access this module doesn't
have an ONLY clause; there's nothing to hide here. It's best put
in the same source file as the main program.

For some reason, many books don't explain this use of the MODULE
(well, actually the few, mostly Japanese, books that I've seen don't,
I haven't really seen all the other books, but that's what I suspect).
Perhaps this use of the MODULE is not mentioned because it is not really
the role of a module in the general programming concept sense. It is
only an extension of the main program, using the MODULE scheme because
Fortran's MODULE can be used that way. Books do explain internal
procedures for this use. The difference between (main program+program's
own module) approach and (main program+internal procedures) approach
is that, with the latter there is no way to distinguish between
entities "local" strictly to the main program and entities that should
be "global" throughout the routines that make up the program.
The former is just a simple to use (for people who know alreay what a
MODULE is) and more general alternative to internal procedures.

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.
--
Yasuki Arasaki
[log in to unmask]