[erlang-bugs] Document of lists:append/2

[Siraaj Khandkar]

Generally, it might be desirable to guard it with is_list/1, but in
this particular case - a bunch of people rely on improper lists for
optimizations, so it isn't so straight forward :/


On 2/10/14, 1:37 AM, Heinz Nikolaus Gies wrote:
> I somewhat disagree on that point. Shouldn’t functions crash given
> badly typed inputs? That sounds like the reasonable thing to to
> when following the fail early paradigm and I always got the
> impression a lot of the functions in the core libraries happily die
> a tragic death if a wrong input comes too close to them. --- 
> Cheers, Heinz Nikolaus Gies heinz@REDACTED
> 
> 
> 
> On Feb 9, 2014, at 11:43 PM, Bob Ippolito <bob@REDACTED> wrote:
> 
>> If you assume that all functions have undefined behavior when
>> given incorrectly typed inputs, it's perfectly consistent. Erlang
>> code tends to assume correctly typed input because it's simpler
>> to implement and the types can often be checked mechanically with
>> tools such as dialyzer.
>> 
>> On Sunday, February 9, 2014, Yoshihiro Tanaka
>> <hirotnkg@REDACTED> wrote: Right. I guess I'm questioning the
>> accuracy of the document.
>> 
>> 
>> On Sun, Feb 9, 2014 at 7:52 PM, Siraaj Khandkar
>> <siraaj@REDACTED> wrote: This is just a surprising side
>> effect of dynamic typing. To perform the append, the left list is
>> traversed and the right is just blindly used as a tail, so it is
>> never introspected and thus never has an opportunity to crash.
>> 
>> 
>> On 2/9/14, 10:30 PM, Yoshihiro Tanaka wrote:
>>> Hi,
>>> 
>>> In the document
>>> :http://www.erlang.org/doc/man/lists.html#append-2 It says: 
>>> append(List1, List2) -> List3, List1 = List2 = List3 = [T], T =
>>> term.
>>> 
>>> But considering the following behavior, it does not look
>>> correct:
>>> 
>>> 1> [] ++ undef. undef 2> undef ++ []. ** exception error: bad
>>> argument in operator  ++/2 called as undef ++ [] 3> [a,b] ++
>>> undef. [a,b|undef] 4>
>>> 
>>> 
>>> Thoughts ?
>>> 
>>> 
>>> Thank you Yoshihiro