This is an interesting aspect that you touch on here - that involves a crossover between declarative programming and object programming - how flexible and resilient to reuse and extension are routines and functions?

I've always found a high degree of this in both xslt and especially Prolog. In Prolog components of your program are highly compartmentalized - so it is especially easy to grab blocks of code and graft them into another process. The Prolog parsers provide direct support for debugging this also (i.e. if you missed a piece somewhere, or something is undefined / non-deterministic). Similarly in xslt - import is a powerful way of sharing code utilities across multiple applications.

Prolog latterly adopted object oriented techniques, particularly in Java based implementations of Prolog engines, and that was certainly a bonus, although your head could often explode trying to grapple with the nuances of both paradigms in the same box!

Which brings up another aspect here - that I know Michael Kay has waxed on too - memory management. You really need strong memory management tools in the underlying language implementation - and also direct ways to prune solution trees and associated memory objects. Back in the day doing this on a 640k machine was always an interesting challenge. Even today however with Gigabyte memory available, performance can suffer dramatically if too much redundant recursion is going on. Of course detecting that you have entered an indirect infinite loop is also the proverbial challenge for any recursive process - e.g. A references B references C references A - so when you inspect A you have no idea that C will reference back to you again. Saxon does provide extensions that can help with this - providing line sequencing - so you see that this A you are in is the same A that you started from before.

Thanks for the pointer to the paper Gavin. It says that functional programming is about improved modularity and providing better ways to glue modules together:

We shall argue in the remainder of this paper that
functional languages provide two new, very important
kinds of glue. We shall give many examples of programs
that can be modularized in new ways, and thereby greatly
simplified. This is the key to functional programming's
power - it allows greatly improved modularisation. It is
also the goal for which functional programmers must
strive - smaller and simpler and more general modules,
glued together with the new glues we shall describe.

I see the benefits of this. However, is that really what declarative programming is about?

> Another way to look at it is that declarative programming
> tends to look at programs as data, not as instructions... people
> with a declarative mindset tend to generate and manipulate programs,
> just as they would any other data.

Now that seems (to me) to more accurately characterize declarative programming.