David's characterization is somewhat correct, but is also a bit simplistic. The LLVM project does certainly use templates (including partial specialization etc), but we prefer to keep this as an implementation detail in a library. Exposing "complex" template code through the public interface of a library generally make the library "scary" to those developers who don't consider themselves to be C++ gurus. This design point also reduces build time for the LLVM code itself.
If you're building this framework as a bunch of libraries, that means expressivity at all kinds of boundaries that would be strictly "internal" in a monolithic compiler will be limited by your idea of what may scare people. Are you sure this constraint is a good idea?
It's much easier to give concrete examples than abstract arguments. As I mentioned, LLVM does use templates heavily in some libraries. Also, note that David is talking more about the LLVM optimizer and code generator libraries than the clang front-end.
Seems likely there are good reasons to templatize a lexer and lots of other components in a C++ compiler.
Can you give me a specific example of where making the entire lexer a template would be more useful than adding a couple of virtual method calls? It isn't meaningful to lex anything other than a sequence of char's for example, and efficient buffer management (at least in our context) means that the input to the lexer isn't useful as an iterator interface. The point of most of the LLVM design decisions is not to hide from templates: it is to use the right C++ design features in the places where they make the most sense. C++ is a very rich language and offers a wide design space to choose from. Templates are one important piece of this design space, but C++ also offers many other great things. -Chris