I also think that a modern language that uses includes instead of modules is just outright insane.
Using the C preprocessor in a non-superset-of-C language would be a pretty odd choice.
example: http://hackage.haskell.org/package/system-filepath-0.4.10/do...
The same overall design could be used to implement many textual macro preprocessors, such as runoff, makefiles, etc.
I've written a couple of macro processing programs, including a make, so I know this kind of program can work with that.
Or another way of putting this is—you speak compellingly about both the algorithm side and the constant side (no tokenizing), but you don't speak about "real world" performance when interacting with many levels of caches, processes, and filesystems. Could you speak to this at all?
BTW, of course if a preprocessor is integrated with another program, Warp can't replace it. It can replace standalone use of a preprocessor.