While reading, researching and experimenting for my macros project the terms in the title get mixed a lot. I'll try to summarise what is my understanding of a lot of the above. To be fair, most of these words are heavily overloaded with sometimes contradictory and or ovelapping meanings, so this short is only about my personal summary, no pretence for a general study or lit review.

Generic programming intuitevely corresponds to design patterns, or a tool to implement them. There should be a distinction between the functional or algorithmic side of the term and the structural or data (type) genericity.

The algorithmics can be handled using higher order functions or combinators. Generally speaking, procedures taking other procedures as arguments, and defining a particular shape of an algorithm. You can meet quite a few examples, sort routines in quite a few languages do that.

Polymorfism, higher order typing, dynamic typing, algebraic data types play their role too. They allow the programmer to think in generic terms about the data, with regards to the task at hand. For example, to implement a quick sort of any collection, we need to be able to somehow walk the said collection, compare its elements, construct a new collection. If we can identify these, we should be able to use a generic version of the quick sort algorithm. Of course, we need to parametrise the algorithm with the appropriate versions of the needed functions.

There is a third side of the generic programming, conveniet syntactic sugar. This is where syntax-transformers or macros join the fun. They allow us to intoduce convenient notation - the haskell list comprehensions are a good example for this. The idea is that you are not really changing the language, just the surface syntax. Well, having said that, in languages with powerful macro systems like scheme and dylan you will find that a lot of what you think is a core language feature is actually implemented as a macro, a kind of a compile time code generation abstractions.