[erlang-questions] definition of iolist

[David Mercer]

On Friday, August 31, 2007, Kostis Sagonas wrote:
> PS. I've repeatedly mentioned to the OTP group that there is very little
>      reason for an IOList to allow binaries in the tail.

And what did they say?

>      Allowing binaries in the tail of the list only saves one cons cell
>      but it disallows the use of many/most lists functions for IOLists.
>      For example lists:length/1 cannot be safely used for IOLists because
>      its use may or might not throw an exception.

Good point.

>      IMO, IOLists should not allow for binaries in the tail position.
>      Other than that, IOLists are great.

I had an aha! moment last night thinking about this (yes, two weeks late,
but it had to be queued in a LIFO stack in my mind until I had brain cycles
to spare), and I thought that iolist() probably permits a binary() as the
tail because a binary() is an iolist()!  By allowing it in the tail,
iolist-processing functions can recursively call themselves on the tail of
an iolist() and if it's a binary(), everything's OK.  Cool.

Tried this to test:


	5> erlang:iolist_to_binary(["abcdefg"| <<"h">>]).
	<<"abcdefgh">>
	6> erlang:iolist_to_binary([<<"h">>]).           
	<<"h">>
	7> erlang:iolist_to_binary(<<"h">>).  
	<<"h">>
	8> erlang:iolist_to_binary("h").    
	<<"h">>
	9> erlang:iolist_to_binary($h). 
	
	=ERROR REPORT==== 12-Sep-2007::15:55:56 ===
	Error in process <0.36.0> with exit value:
{badarg,[{erlang,iolist_to_binary,"h"
	},{erl_eval,do_apply,5},{shell,exprs,6},{shell,eval_loop,3}]}
	
	** exited: {badarg,[{erlang,iolist_to_binary,"h"},
	                    {erl_eval,do_apply,5},
	                    {shell,exprs,6},
	                    {shell,eval_loop,3}]} **

So far my, my theory was right.  Line 7 passes a naked binary to
erlang:iolist_to_binary/1 and it works.  Line 9 shows that a naked
character, on the other hand, is not acceptable, consistent with my theory.

BUT it turns out there is another inconsistency with iolists, and that is
that erlang:iolist_to_binary/1 is documented as accepting an
iolist()|binary().  So instead of their being consistent in my mind, they
become even more inconsistent by naming a function iolist_to_binary which
does not have the type iolist() -> binary() as you might expect.  No, that
function is named list_to_binary, which is quite bizarre.

Cheers,

DBM