Operand inversion in motov.c

[David Hakim]

Hmmm ... what to do here is a tough question to answer. I'd like to do
some expression evaluation tests in other languages to see the order in
which assignments get evaluated in them. A test like

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.

-Dave

Hi Dave,
I had to invert the order of evaluation in motov_assign, cause
otherwise I had
no rval available to check operator existence in motov_array_rval.
Before it
/* 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);
/* Get the RValue from the right side */
motov(uc_operand(p, 2));
rval = opstack_pop(env);
/* Save current rval value */
env->current_rval = rval;
/* Get the LValue from the left side */
motov(uc_operand(p, 0));
lval = opstack_pop(env);
/* Clear current rval value */
env->current_rval = NULL;
Of course, the previous version was much better from a verifier point
of view,
because you could first verify the left side of the assignment and
then the
right. But the inversion is the only way to produce the rval before
motoi_array_lval gets called.
The bf_comments test fails now, but just because the print order of
the error
messages is inverted.
bf_comments.moto.................fail.....ok.......n/a......n/
a......n/a
What should we do? Change the test or find another way to evaluate
lval []
overloaded operators?
Stefano

[Stefano Corsi]

Post by David Hakim
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

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

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.

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

[David Hakim]

Post by Stefano Corsi

Post by David Hakim
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.

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)

Post by Stefano Corsi
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 :)

Post by Stefano Corsi
However, there is already an inconsistence in the present code, because in
/* 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

Post by Stefano Corsi
/* 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