Re: Re: Operand inversion in motov.c

On Tuesday, May 6, 2003, at 07:26  PM, Stefano Corsi wrote:

>
>> int output (int i){ print i; return i;}
>> foo[output(27)] = 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
>
> ...on the other side in perl is right to left...
>
> 30
> 27
>
> ...while php is left to right...
>
> 27
> 30
>
> ...but python is right to left
>
> 30
> 27
>

Heheh ...  too funny :) I think we should try C++ and Java just for 
laughs. But if they disagree also, since there is so much inconsistency 
in the other languages, I suppose we could evaluate right to left just 
this once :) we would likely have to change the compiled form as well 
though (see notes on this later)

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

Right to left is sort of counter-intuitive if you ask me ... but I'm 
not that picky :)

> However, there is already an inconsistence in the present code, 
> because in
> moto_0_19_1 motov.c does:
>
>     /* Get the LValue from the left side */
>     motov(uc_operand(p, 0));
>     lval = opstack_pop(env);
>
>     /* Get the RValue from the right side */
>     motov(uc_operand(p, 2));
>     rval = opstack_pop(env);
>
> while both motoc and motoi do the opposite. This means that we verify 
> the code
> from left to right and execute and interpret it from right to left. 
> Don't
> really know what are the implications and side effects, but doesn't 
> sound
> good.

Heheh ... I don't know that the implications of verifying and 
interpreting in different order are so bad. What would be bad is having 
compiled code that evaluates from left to right and interpreted code 
which evaluates from right to left.

We may end up with that since the compiled code output for an 
overloaded operator will be a function call that takes the left hand 
side as its first argument. This is probably a good reason to change 
things so we interpret left to right. No matter what we decide though, 
compiled and interpreted semantics must be the same.

-Dave

> Now, with operator overloading all three functions are evaluating like 
> this:
>
>     /* Get the RValue from the left side */
>     motov(uc_operand(p, 2));
>     rval = opstack_pop(env);
>
>     /* Get the LValue from the right side */
>     motov(uc_operand(p, 0));
>     lval = opstack_pop(env);
>
> At a first glance seems reasonable, because first we create a value ( 
> on the
> right side), then we assign it to the left side. We are supported by 
> perl,
> and python while C and php do the opposite... and Java? ... well ... 
> I'm too
> lazy tonight to create java class for this ...
> What do you think?
>
> Stefano
>