<div dir="ltr"><div>Yes, I think it was a mistake not to include atoms in iolists to begin with (funnily, filenames can be deep and include atoms, but iolists can't). It might be pretty hard to change though, since there is so much existing code that might crash if it stumbled over an atom in a list that was produced by more modern code.<br><br></div><div>Several functions in the standard libraries become needlessly expensive because of this need to expand atoms before they can be included in iolists, even when the result is just going to be sent directly to a file or port.<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><br>        /Richard</div></div>
<br><div class="gmail_quote">On Mon, May 25, 2015 at 6:59 PM, Antonio SJ Musumeci <span dir="ltr"><<a href="mailto:trapexit@spawn.link" target="_blank">trapexit@spawn.link</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">There are situations where atoms are mixed with strings such as filenames and it'd be nice to not need to flatten and convert them. There are other situations where knowing an atom would be converted to it's string form would be more efficient and convenient than the alternative.</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On May 25, 2015 12:44 PM, "Fred Hebert" <<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/25, Antonio SJ Musumeci wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does anyone know of any backwards incompatibility which could arise if<br>
atoms were added to the iodata() and iolist() definitions?<br>
<br>
iolist() = maybe_improper_list(byte() | binary() | atom() | iolist(),<br>
binary() | [])<br>
iodata() = iolist() | atom() | binary()<br>
</blockquote>
<br>
Why would you do that?<br>
<br>
But yes, there could be incompatibilities. For example, the `iodata()` type is defined in terms of `iolist()`, and operations such as `erlang:port_control()` return `iodata()` as a type. As such, operations to port programs could now technically start returning atoms to code that won't expect such things.<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>