Atoms in I/O lists
Wed Dec 15 08:54:39 CET 2004
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
More information about the erlang-questions