List append buglet...?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

List append buglet...?

Andrew Shelton

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 current.

--
"Oh, drat these blasted computers.  They're so naughty and complex. I
could pinch them!" Marvin the Martian.

My web page : http://www.serc.rmit.edu.au/~ashelton


Reply | Threaded
Open this post in threaded view
|

List append buglet...?

Mickael Remond-2
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).

What is funny is that the function cannot be reversed:
8> {1}++[].

=ERROR REPORT==== 5-Feb-2001::10:59:22 ===
Error in process <0.34.0> with exit value: {badarg,[{erlang,append,[{1},[]]},{erl_eval,eval_op,3},{erl_eval,expr,3},{erl_eval,exprs,4},{shell,eval_loop,2}]}
** exited: {badarg,[{erlang,append,[{1},[]]},
                    {erl_eval,eval_op,3},
                    {erl_eval,expr,3},
                    {erl_eval,exprs,4},
                    {shell,eval_loop,2}]} **


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.

Apparently, only the first argument is check to see if this is a list. The
second one is not checked and can be anything.

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.

--
   Micka?l R?mond                    tel :      (33)1.44.42.00.00
   Chef de projet                    mob :      (33)6.60.22.22.16
   15 - 17 avenue de S?gur           e-mail :   mickael.remond
      75007 - Paris                  web :      http://IDEALX.com


Reply | Threaded
Open this post in threaded view
|

List append buglet...?

Robert Virding-4
Mickael Remond <mickael.remond> 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
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".




Reply | Threaded
Open this post in threaded view
|

List append buglet...?

Mickael Remond-2
On Mon, 05 Feb 2001, Robert Virding wrote:

>
> 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.

Ok.
Thank you for helping us to understand the behaviour of the append function.
I did not think about linking that to the 'cons' behaviour and your answer is
convincing: this is how the system is working and not a misbehaviour.

Thank you.

--
   Micka?l R?mond                    tel :      (33)1.44.42.00.00
   Chef de projet                    mob :      (33)6.60.22.22.16
   15 - 17 avenue de S?gur           e-mail :   mickael.remond
      75007 - Paris                  web :      http://IDEALX.com