Hate to be the Debbie downer here, but this is kind of boring. Since templates are well-known to be Turing complete[1], writing a more "pure" functional wrapper around them (essentially what Fulmar is) is not really that interesting. The paper claims that this kind of code-generation simplifies the task of maintaining a code-base. I'm not really convinced. It also claims that the generated code is easy to debug. I fear that this is straight-up disingenuous. Go make a template blow up in C++ and try to decipher what the hell you did wrong.
You should be very wary of abusing templates like this. It seems that the general C/C++ trend is to replace one monster (preprocessor macros), with another bigger and badder one. The horror (the horror![2]).
Author here, and I agree that using templates for complex code generation is a mess. However, it's a popular mess in some branches of high performance computing right now, especially for dealing with the transition to execution on GPUs. If you're stuck in C++ and want abstraction without runtime cost, templates are what you've got. An alternative option is to step outside of C++ and write a compiler or source-to-source translator in a more suitable language (the direction we've gone since), but that means existing C++ programs can't just drop in your DSL as a library without adding more bits to their toolchain.
If you do decide to make a complex library based on template meta-programming, you inevitably end up needing a meta-meta language to help build it because templates are so ill-suited to the task (especially before C++ 11). Many template-based libraries (like Eigen, http://eigen.tuxfamily.org/) have chosen to use preprocessor macros as that meta-meta language; we decided Racket was a better choice and this paper is our exploration of how that might work. I suppose an interesting takeaway is that even if user constraints force you to implement your DSL compiler as a template meta-program, you can still use an outside meta-meta language to help create the templates.
The statements regarding debuggability make two claims that I think are correct, if not particularly strong: 1. using Fulmar as a meta-meta language produces a more readable template meta-program to examine than do preprocessor macros; 2. Fulmar can catch some errors at the meta-meta level and provide nice errors (section 4.5) in places you might have otherwise received the nasty template expansion errors (again unlike preprocessor macros).
I've been working on a similar project for a while ( https://github.com/elfprince13/RacketMacros4Cxx ), and I should also point out that while templates are Turing complete, that only means you can express arbitrary computations. It doesn't mean you can express arbitrary (hygienic) manipulations of syntax trees, which is more typically what you want to accomplish with metaprogramming
Also, once you have Racket macros, you quickly discover you don't really need templates any more either.
See section 4 of https://drive.google.com/open?id=0Byxgs15FUp2QRHJRVFVBLTZZc1... for some good examples rewriting code that Nvidia shows off as good examples of "how to optimize CUDA" to something that doesn't look like someone had an accident with copy/paste.
C++ TMP, being a pure functional language, tends to compose well. I developed a standalone recursive template expansion today, bit by bit, checking it as I went using a typeid().name() + GNUs abi::__cxa_demangle + clang-format hack, and then integrated it into a project. Worked first time. Writing the resulting template by hand would have been incredibly error-prone.
Racket is a lisp (more precisely it's a descendent of Scheme). LISP in all caps generally refers to McCarthy's original description and the first few implementations.
You should be very wary of abusing templates like this. It seems that the general C/C++ trend is to replace one monster (preprocessor macros), with another bigger and badder one. The horror (the horror![2]).
[1] http://stackoverflow.com/questions/189172/c-templates-turing...
[2] https://www.youtube.com/watch?v=rDK9MDklzFo