<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="gmail_quote">On May 25, 2015 12:44 PM, "Fred Hebert" <<a href="mailto:mononcqc@ferd.ca">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>