<br><br><div class="gmail_quote">2013/2/14 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 02/14/2013 11:18 PM, Björn-Egil Dahlberg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Creating atoms in runtime. It should only have been allowed in code<br>
and never by list_to_atom/1 or binary_to_atom/1,2 (binary_to_term would<br>
still be a thing though)<br>
</blockquote>
<br></div>
Anthony Ramine has a "split the atoms" implementation of ROK's EEP in progress which allows to dynamically create garbage-collected atoms, fixing all issues related to creating them at runtime. You might want to take a look or help getting this in quicker:<br>
</blockquote><div><br></div><div>My point was actually not to have atoms as strings (and prolog filenames).</div><div><br></div><div>If I'm reading the EEP correctly: a local atom would actually require a larger heap space than an equivalent heap binary .. which is a feat all by itself.</div>
<div><br></div><div>I gather that could be remedied though. Haven't looked at the code.</div><div><br></div><div>I agree that atom gc is needed but it shouldn't be an excuse for using dynamic atoms instead of binaries. Besides, if locals atoms are larger than binaries why would you use atoms. (I might be wrong about the size though .. didn't look that hard).</div>
<div><br></div><div>// Björn-Egil</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  <a href="https://github.com/nox/otp/tree/eep20" target="_blank">https://github.com/nox/otp/<u></u>tree/eep20</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Loďc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
</font></span></blockquote></div><br>