<div dir="ltr">One thing more (to not create extra thread)<div><br></div><div>In the documentations there are notes describing some options behaviour, e.g.<br>> The options {nowarn_unused_function, FAs}, {nowarn_bif_clash, FAs}, and {nowarn_deprecated_function, MFAs}</div><div>> are only recognized when given in files. They are not affected by options</div><div>> warn_unused_function, warn_bif_clash, or warn_deprecated_function.</div><div><br></div><div>It's hard to notice them if you read about affected options — this note is almost 2 screens below</div><div>the nowarn_deprecated_function description.</div><div><br></div><div>Maybe it would be easier to read the note if affected options had a link to it, e.g.</div><div><br></div>> {nowarn_deprecated_function, MFAs}<br>> <div>> (This option works only when given in a file and has a precedence over <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">warn_deprecated_function</span> option. See Note [4] for details)<br>> Turns off warnings for calls to deprecated functions likenowarn_deprecated_function<div>> does, but only for the mentioned functions. MFAs is a tuple {Module,Name,Arity} or a list of such tuples.</div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 6, 2018 at 1:16 PM, Danil Zagoskin <span dir="ltr"><<a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi!<div><br></div><div>I had a simple task: get an AST of a module (.erl) after preprocessing it (includes + parse_transforms).</div><div><br></div><div>I read the docs: <a href="http://erlang.org/doc/man/compile.html" target="_blank">http://erlang.org/doc/<wbr>man/compile.html</a></div><div>This is how I first understood some options:</div><div>* 'P' — get a transformed code instead of a compiled module</div><div>* 'binary' — get a result in return value instead of a file</div><div><br></div><div>So, I run compile:file("example.erl", ['P', binary]) and indeed get an AST in third position of returned tuple.</div><div>Surprise: example.P file is still written on disk, and it contains Erlang code, not the returned AST.</div><div><br></div><div>Reading the compile.erl I found an undocumented 'to_pp' option.</div><div>Passing 'to_pp' alone also generates example.P file, but this time it contains AST.</div><div>Passing both 'to_pp' and 'binary' works as I wanted — AST in returned tuple, no files written.</div><div><br></div><div>My suggestions:</div><div>* make 'binary' (well, naming legacy) always switch from only writing to file to only returning result.</div><div>* associate every content with its own file extension (e.g. example.ast for AST)</div><div>* document 'to_pp' and other options</div><div><br></div><div>This would make using compiler in non-trivial way easier:</div><div>* choose at which pass should compiler stop</div><div>* choose where the result goes</div><div><br></div><div><br></div><div>Any thoughts on this?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- <br><div class="m_9105521148705845441gmail_signature"><div dir="ltr"><div><font face="'courier new', monospace">Danil Zagoskin | <a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a></font></div></div></div></div></font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><font face="'courier new', monospace">Danil Zagoskin | <a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a></font></div></div></div>
</div>