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

www.quickthreadprogramming.com
11 posts / 0 nouveau(x)
Dernière contribution
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

www.quickthreadprogramming.com

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 101Push token /Push token 7Push token +Push token 5(push or detect token ;)Pop 5Pop +Pop 7--- Do operationPop /Pop 101--- Do operationwhich would be the same as: (5 + 7) / 101Even parens don't help much if you are use to LTR eval. / 101 + 7 5 evaulate <<< RTLwhich evaluated LTR would be (101 / 7) + 5, but RTL becomes (5 + 7) / 101Did I mention weird :-DIf 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 + 5when parsed RTLgives parse tree of/(101, +(7,5))evaluating:101/128.41666666667Just 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.42857142857john

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 asc -> bb -> aThe analogous intetpretation of10 + 15 / 5is(15/5) -> temp(10 + temp) -> result

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui