<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 28, 2016 at 7:52 AM,  <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> Hi,<br>
> I see an interest in keeping all source code in abstract code at least as<br>
> a compilation option.<br>
<br>
</span>By the time you have included the original spelling of every token,<br>
all white space, and every comment in your AST (which is what Joe<br>
was talking about), you have replicated the *concrete* form of the<br>
source code, just broken up into little bits.  </blockquote><div><br></div><div>Yes, and sometimes this is just what one needs. Any tool that processes/transforms source code </div><div>needs an AST for the source _before preprocessing_, so that </div><div>it can know about macros and ifdefs. Then cross-referencing will include all types of tokens and all </div><div>instances of those, not just those that survived the preprocessor. This is useful for example when </div><div>renaming a function or macro. Even pretty-printing can use this (for example to gray out the parts of the</div><div>source that are currently removed by the preprocessor).</div><div><br></div><div>Newer code is much nicer to parse, as heavy usage of macros and ifdefs is avoided, but</div><div>there is always old code that nobody really wants to touch, but has to be considered. Also we need to</div><div><div>consider the proposed OTP version macros (EEP 44 <a href="https://github.com/erlang/eep/blob/master/eeps/eep-0044.md">https://github.com/erlang/eep/blob/master/eeps/eep-0044.md</a>)</div><div>that would make it possible to provide multiple versions of a function in the same file, each possibly with their own</div></div><div>edoc documentation blob (even if it is arguably better to keep the docs separate, a lot of projects today</div><div>use inline docs with edoc).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If you record the<br>
source code (in some compressed form), and you record the start and<br>
length of every term, you can extract the source code for any term<br>
effortlessly, no concatenation required.<br>
<br>
We already have the option to store an AST in a BEAM file,<br>
I believe.<br></blockquote><div><br></div><div>Yes, the key word being _an_ - some use cases need another AST. Processing source code</div><div>for compiling has different requirements than for searching/transforming it.</div><div><br></div><div>best regards,<br></div><div>Vlad</div><div> <br></div></div></div></div>