I’m writing a demo compiler for a toy programming language in C.
What problems can arise if we do macro processing in a separate phase between reading the program and lexical analysis?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m writing a demo compiler for a toy programming language in C.
What problems can arise if we do macro processing in a separate phase between reading the program and lexical analysis?
“Preprocessor” generaly means a tool that transforms the codes before the main compiler gets a hold of it.
That is the preprocessor lexes (and possibly parses) the source by its rules, performs some transformation and outputs a result. The main compiler lexes and parses the result of the preprocessor’s work according to its rules (which may be different from those used by the preprocessor).
So if the preprocessor works non-trivial changes on the program text it can be hard to predict the final result at a glance. This is true of c with the c-preprocessor, but (or perhaps thus) convention holds that you should only use the preprocessor in a few ways that have fairly predictable results. (
I believe that the c preprocessor is Turing complete, so there is no limit to what can be achieved if you don’t go insane trying to debug it.On thinking about Pavel’s comment, I concede no loops, no recursion, no stacks. Seems like that kills it. Thanks. You can still go bonkers trying to debug a sufficiently advance pile of macros.)