<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 13, 2015 at 9:49 AM, Raimo Niskanen <span dir="ltr"><<a href="mailto:raimo+eeps@erix.ericsson.se" target="_blank">raimo+eeps@erix.ericsson.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">New - EEP 44: Additional preprocessor directives<br>
<br>
    <a href="http://www.erlang.org/eeps/eep-0044.html" rel="noreferrer" target="_blank">http://www.erlang.org/eeps/eep-0044.html</a><br>
    <a href="https://github.com/erlang/eep/blob/master/eeps/eep-0044.md" rel="noreferrer" target="_blank">https://github.com/erlang/eep/blob/master/eeps/eep-0044.md</a><span><font color="#888888"><br></font></span></blockquote><div><br></div><div>From my point of view (which I can agree that is not shared by most others), I would much prefer that the preprocessor would be as feature-thin as possible. As pointed out, it is the macros that are the source of most problems, but I write my own parser to handle code with conditional compilation and if I didn't need to do that I would be much happier.</div><div><br></div><div>That could be handled, I think, by trimming the code after it has been parsed. That is, let the parser understand about -ifdef, -if and friends and build a corresponding parse tree that is pruned before being sent to the compiler. Unfortunately, I can't see any good way to make that backwards compatible - tools can't just ignore the new tree nodes, so I will most probably have to accept having to reimplement the preprocessor's job myself. </div><div><br></div><div>I don't see this as a negative point for the EEP, but for the preprocessor in general, and I felt I had to get it off my chest :-)</div><div><br></div><div>regards,<br></div><div>Vlad</div><div><br></div></div></div></div>