I mentioned in another post that a C program could be parsed to the extent to allow better checking. Not to the point where you'd build a gcc-look-alike, but just enough for instance to know the type of the expression, and if the expression used in Vely statement is correct, and such. Perhaps that's something to consider. I thought about it here and there, but found it to be more useful to check for logical conflicts, such as not providing required arguments, balancing beginning and end of multi-part statement, incorrect usage and such. Typically, using the wrong type accounts for most of the issues, and gcc produces very good messages. Again those messages get matched to the source Vely file exact line number, and I found that correcting an issue isn't difficult.
Your tool sounds great, and if it works what you need it do, awesome! I do things like that all the time, and find that often times using tools is an overkill, and just skip it. There's time and place for everything.
The problem I usually have is matching C-compiler error messages to $NEWLANG errors.
Like I said, as long as the programmer is aware that it's a preprocessor for the language and not an AST-based code generator, then there usually isn't a problem. I used ecl (or gcl, not sure now) that went the AST code-generation path and it worked much better than any preprocessor-based method in terms of compilation errors and diagnostics.
PS. In case you (or anyone else) is wondering about my mentioned HTML preprocessor, I put it into a gist: https://gist.github.com/lelanthran/603a24c56bc3afc1370a007a0...
This means that all the diagnostics being emitted will be very confusing. When incorrect input is given, Vely doesn't produce the error message, gcc does, which makes it difficult to match the error message to what the user actually typed in.
I've used (and created many[1]) "embedded" languages, and this is the biggest problem with those that simply do pattern matching and replacement: the language the programmer is writing is unaware of errors and the programmer has determine what they did wrong by looking at the generated code.
It's not a big problem if the programmer understands this limitation; that the "language" is a macro language that blindly transforms input to output with no understanding of the input. If the programmer accepts this, it can be very useful.
[1] I just created a html preprocessor in bash this morning. It performs variable substitution using environment variables and runs the C preprocessor on the input, allowing #include directives, #ifdef, etc. It lets me write my HTML files in fragments that can conditionally include other HTML files, and it lets me put in variables in the HTML file that are substituted with values from the environment.
I've no doubt that this is a hacky solution, but
a) It took only an hour to write (thus far - there's some TODOs in there for stuff that might be useful in the future)
b) It was quicker than downloading and learning to use an existing tool that does the same thing, and ensuring that all that tools dependencies are brought in as well.