# Rules (apparent) inconsistancy right-to-left versis left-to-right

## Rules (apparent) inconsistancy right-to-left versis left-to-right

We have been hashing the expression evaluation order as to right-to-left versis left-to-right for some time in other threads with the apparent "official" position as being right-to-left.

I would like to point out then an apparent inconsistancy with this rule (I say apparent because the results were not stated but are implied).

In the description for string operators (concatination) you have

var strConcat = str1 + str2 + str3;

The output for this was not shown, but I would imagine everyone expects the output to be:

{contents str1}{contents str2}{contents str3}

Following right-to-left rule the results have to be

{contents str2}{contents str3}{contents str1}

So what is it?

Jim

11 posts / 0 nouveau(x)
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

The ad hoc way the rules were formulated meant there was no chance I would give 50+ hours of my time to producing a solution, when there is no clear idea of what we are shooting for, nor test cases. Simple does not mean vague. You can be simple, we well as precise, concise and clear. Giving the problem a vague definition does not make it inherently simpler. In fact the contrary.

Hmmm, I'd kind of expect it to be: {contents str3}{contents str2}{contents str1}

I thought about that too, but my interpretation is you have

var1 op var2

and in the case of op == / then you have var1 divided by var2.
Right to left for

var1 op1 var2 op2 var3

my guess is

var1 op1 (var2 op2 var3)

Now that I look at it this way, for text concatination, the result would be var1var2var2 (although the right two results would be produced first).

Slugging along.

I haven't yet completed my parser. May make some progress this weekend.

Had a leaky water pipe I had to fix, this slowed me down. This was a real simple job, or so it seamed at the beginning.What should have been a 10 minute job ended up being a half a day's work. Kind oflike some programs we write.

Jim

I would assume that true RTL evaluation (which is really weird) would be like this: var a = 101 / 7 + 5; (scaning LTR): After detecting token = Push token 101 Push token / Push token 7 Push token + Push token 5 (push or detect token ;) Pop 5 Pop + Pop 7 --- Do operation Pop / Pop 101 --- Do operation which would be the same as: (5 + 7) / 101 Even parens don't help much if you are use to LTR eval. / 101 + 7 5 evaulate <<< RTL which evaluated LTR would be (101 / 7) + 5, but RTL becomes (5 + 7) / 101 Did I mention weird :-D If I understand what you are thinking you are interpretting it as: (101 / (7 + 5)) Which evaluates each operational pair LTR then combines them RTL. To me that's like seeing an english word written in a RTL natural language (the language might be RTL, but the english word is LTR). That could be what they mean but I'm not sure what kind of order to call that :-)

@dweeberlyloom: Oh, no... IMHO you are confused about what RTL evaluation means.
101 / 7 + 5 when parsed RTLgives parse tree of /(101, +(7,5)) evaluating: 101/12 8.41666666667 Just because you parse RTL, doesn't mean you change the operand orders. On the other hand, an LTR parse would yield: +(/(10,7), 5) evaluating: +(1.4285714285, 5) 6.42857142857 john

You could easily be right, but what you are suggesting seems more like a bottom up as opposed to top down evaluation of the expression tree. I've never seen any sort of expression parsing that is RTL, the only thing I know to compare it to is natural languages.

That is truebut not the same (in my mind) as LTR evaluation. 'a=(b=c)' is the recursive application of LTR evaluation.

Consider the prefix and postfix operators in C

++a
a++

prefix operates RTL, while postfix operates LTR (in C '=' is RTL) Normal operations like '+' are (in C) evaluated LTR, but we are being ask to evaluate the entire expression RTL. In some ways for our purposes this can have advantages, but it's 'weird'.

Again, your interpretationmay very well be correct, but the vagueness of the language description to this point leaves me with doubt.

@Jim, I agree that the specification of the expression evaluation order is unusual, but I think that we should run with a fairly standard interpretation of RTL evaluation such as that semantics of the '=' operator in C. That standard definition does not change the order of the operands, it only changes the associativity of the operators. So 10/5 is 2, not 0.5. In other words, a = b = c; is interpreted as c -> b b -> a The analogous intetpretation of 10 + 15 / 5 is (15/5) -> temp (10 + temp) -> result