Atoms in I/O lists

[Raimo Niskanen]

I do not have strong and hard objections, rather soft and swampy.

No, atoms cannot be unicode. Erlang's character map is ISO-8859-1.
Strings (lists) might have unicode characters one day, though,
since it would only mean relaxing the 0..255 range reqirement.

1) If we would allow atoms in I/O lists, why not then also floats and all
other basic types that have TYPE_to_list/1 BIFs. Internal rewrites might
be bigger than expected, e.g the flattening to a buffer has got two
passes - one to determine the size and one to write the data so
all TYPE_to_list/1 BIFSs would need internal associates a'la
TYPE_list_size/1. Plus the fact that all TYPE_to_list/1 functions 
create erlang lists, not byte buffers.

2) It is not only sending to a port that uses I/O lists. The I/O
functions in io.erl, io_lib.erl, etc uses a subset :-) of I/O lists,
without binaries, as allowed string for the format character ~s.
Would we have to allow atoms in such strings too?

3) A lot of application code out there probably mangles I/O lists
as they are known today. Such code would have to be rewritten.

So, I feel I did not present a particulary strange case against
allowing atoms in I/O lists. Then it depends on how strong
the cusomer demands are...



jamesh@REDACTED (James Hague) writes:

> An I/O list is list where each element is an integer in the range 0-255, a
> binary, or another I/O list.  Several times now I've wished that atoms could
> be directly included in I/O lists rather than having to call atom_to_list
> first.  With atoms legal in I/O lists, you could imagine atom_to_list call
> quietly wrapped around each atom.  In addition to being simpler, this could
> result in less garbage being generated, assuming that I/O lists get parsed
> in the C runtime.
> 
> One reason I can think of for not allowing this is if atom names can be
> Unicode.  I don't know if Erlang supports this.  Are there other objections?

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB