[erlang-questions] atoms in iodata() / iolist()

[Richard Carlsson]

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.

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.


        /Richard

On Mon, May 25, 2015 at 6:59 PM, Antonio SJ Musumeci <trapexit@REDACTED>
wrote:

> 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.
> On May 25, 2015 12:44 PM, "Fred Hebert" <mononcqc@REDACTED> wrote:
>
>> On 05/25, Antonio SJ Musumeci wrote:
>>
>>> Does anyone know of any backwards incompatibility which could arise if
>>> atoms were added to the iodata() and iolist() definitions?
>>>
>>> iolist() = maybe_improper_list(byte() | binary() | atom() | iolist(),
>>> binary() | [])
>>> iodata() = iolist() | atom() | binary()
>>>
>>
>> Why would you do that?
>>
>> 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.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150525/a8d3ca3f/attachment.htm>