Hi,

I've found this strange behavior when you evaluate instructions inside for and while loops;

IMHO the direct evaluation ( = , -> ) inside loops could be (simply?) inhibited without any losses


regards,

w3b5urf3r

---

Hi,

Wrote

Hi,

I've found this strange behavior when you evalutate instructions inside for and while loops;

IMHO the direct evalutation ( = , -> ) inside loops could be (simply?) inhibited without any losses


regards,

w3b5urf3r

I guess that symbolic or numeric evaluation is already inhibited inside any expressions. Wherever you submit = or ->, the operator is put to the end of the complete expression, in this case at the end of the for or while loop or the if statement. In contrast to this, the assignment operator can be used in whatever substructures.

The odd result of for or while loops may be due to that these functions do not provide any return value. Attempt to assign the result of the control structure to a variable fails (syntax error). Perhaps the evaluation operators call a method that the control structure objects just do not provide. In UPN, if you want to use the result of some operation, you have to leave it on the stack. I guess that is where the error message comes from.

[MATH lang = eng]a:while(k<0,2+2)[/MATH]

The if statement returns the value of the corresponding branch and does neither fail to display it nor to provide it for assignment.

[MATH lang = eng]a:if(0<1,2+2,3+3)[/MATH]

results in

[MATH]a=4@#[/MATH]

Back to your proposal of inhibiting evaluation of control structures, an alternative might be to provide meaningful return values. The line operator returns the value of the last statement (what if that is a for loop ?

Loops might return the number of executions, for a while-loop that might occasionally save a separate counter, in a for loop this would be a bit redundant.

Best regards, Martin