List append buglet...?
Robert Virding
rv@REDACTED
Mon Feb 5 14:23:45 CET 2001
Mickael Remond <mickael.remond@REDACTED> writes:
>On Mon, 5 Feb 2001, Andrew Shelton wrote:
>> Greetings,
>>
>> Well, if it wasn't a bug it certainly was suprising behaviour. It also
>> seems to violate the stdlib documentation. Since it's such a basic
>> operation it took me a while to track down what was going on...
>>
>> Erlang (BEAM) emulator version 4.9.1 [source]
>>
>> Eshell V4.9.1 (abort with ^G)
>> 1> []++[1].
>> [1]
>> 2> []++{1}.
>> {1}
>> 3>
>>
>> At least it's simple to demonstrate. Apologies if this has been
>> fixed in the most curent.
>
>I do not know what you were expected exactly, but the behaviour of the list
>appending function is still the same in the last Erlang version (5.0.1.1).
Actually this is completely consistent with the behaviour of cons ([|]).
Try doing:
1> [a|[]].
[a]
2> [a|b].
[a|b].
3>
There is nothing which forces the tail of a list to be a list or nil!
So, as append/++ behave as if they were defined as:
append([H|T], Rest) -> [H|append(T, Rest)];
append([], Rest) -> Rest.
the result is quite correct, logical and consistent. Append is defined
in section 3.2.2 of the book (which is in the down-loadable section).
>What is funny is that the function cannot be reversed:
>8> {1}++[].
See above.
>Moreover, I discovered that the "++" operator is used in the lists:append/2
>function. I thought that ++ was a syntaxic sugar for the lists:append
>function, but this does not seem to be the case.
>Thus, you get exactly the same result in the list append function.
Actually which is syntactic sugar for which is really irrelevant,
lists:append is a function interface and '++' is special syntax for a
common case.
>Apparently, only the first argument is check to see if this is a list. The
>second one is not checked and can be anything.
See above
>If the first element is an empty list, so the second element is directly sent
>back. Thus, the lists:append function does not necessarily send back a list but
>can return anything.
>
>So, I think you are right, this is not consistent with the documentation, and
>I think this is not the wanted behaviour.
Yes, it is consistent, but whether it is the wanted behaviour is another
question. This definition of lists is the same as in Lisp and Prolog
which were languages which strongly influenced the development Erlang.
It would be difficult to change today as a change would have to be made
to all list construction not just for append. Otherwise how would you
efficiently handle cases like:
List ++ [a|b]
Deep-checking the second argument is not really feasible.
Robert
--
Robert Virding Tel: +46 (0)8 545 55 017
Alteon Web Systems Email: rv@REDACTED
S:t Eriksgatan 44 WWW: http://www.bluetail.com/~rv
SE-112 34 Stockholm, SWEDEN
"Folk säger att jag inte bryr mig om någonting, men det skiter jag i".
More information about the erlang-questions
mailing list