Re: Re: Operand inversion in motov.c

> int output (int i){ print i; return i;}
> foo[output(27)] =3D output(30);
>
> would tell us the order in which the left and right sides get evaluated
> ... My overall feeling is that we should avoid having a non-standard
> equals operator. Even if that means we need to re-think our
> implementation of this feature.

In C the order is left to right. The output is:

27
30

=2E..on the other side in perl is right to left...

30
27

=2E..while php is left to right...

27
30

=2E..but python is right to left

30
27

I'm must admit that somewhere in my heart I'm an addicted perl programmer=
,=20
so...

However, there is already an inconsistence in the present code, because i=
n=20
moto_0_19_1 motov.c does:

    /* Get the LValue from the left side */
    motov(uc_operand(p, 0));
    lval =3D opstack_pop(env);

    /* Get the RValue from the right side */
    motov(uc_operand(p, 2));
    rval =3D opstack_pop(env);

while both motoc and motoi do the opposite. This means that we verify the=
 code=20
from left to right and execute and interpret it from right to left. Don't=
=20
really know what are the implications and side effects, but doesn't sound=
=20
good.

Now, with operator overloading all three functions are evaluating like th=
is:

    /* Get the RValue from the left side */
    motov(uc_operand(p, 2));
    rval =3D opstack_pop(env);

    /* Get the LValue from the right side */
    motov(uc_operand(p, 0));
    lval =3D opstack_pop(env);

At a first glance seems reasonable, because first we create a value ( on =
the=20
right side), then we assign it to the left side. We are supported by perl=
,=20
and python while C and php do the opposite... and Java? ... well ... I'm =
too=20
lazy tonight to create java class for this ...
What do you think?

Stefano