Fixed Breaking change in Expression evaluation (.and.) in v17

[WadeHatler]

The lazy evaluation of lines appears to have broken in v17. In v16, .and. appears to be evaluated lazily like in C, etc, but in v17 it doesn't work any more.

I have quite a few batch files with lines like
Iff %2. != . .and. not IsDir %2 Then
Echo %2 IS DIR
EndIff

Prior to v17 they were lazy evaluated, so passing only 1 parameter to the batch file resulted in the target line not being evaluated, and no error.

In v17, this is broken. It produces
TCC: C:\temp\1.btm [1] Unknown command "Then"
IS DIR
TCC: C:\temp\1.btm [3] Unknown command "EndIff"

I can rewrite the offending code as a series of Ifs, but it's pretty annoying, so I'll probably just drop back to 16 until if/when it's fixed.

 

[vefatica]

The behavior is different in v17 (vs. v16). But I'm pretty sure the evaluations were never "lazy" (stop when the truth value is determined). Below, "foo" is echoed even though it was not necessary to evaluate the second conjunct/disjunct of the conditional expression.

v:\> ver

TCC  16.03.55  Windows 7 [Version 6.1.7601]

v:\> type ifftest.btm
iff a == b .and. %@exec[echo foo] == 0 then
echo bar
endiff

iff a == a .or. %@exec[echo foo] == 0 then
echo bar
endiff

v:\> ifftest.btm
foo
foo
bar

 

[rconn]

The evaluation was never lazy (it can't be since the parser doesn't know what combination of .AND. / .OR. / .XOR.'s you might have appended on the right side of the line).

The problem here doesn't have anything to do with the .AND., it's because of the missing argument for ISDIR. V16 had a hack to test for this; I've added it to v17 as well for build 62.

 

[vefatica]

"C" type evaluation of logical expressions (stop expanding/evaluating when the truth value can no longer be changed) would be nice. I don't suppose it would be too hard to write such a routine, but it would need to be able to pass the simple expressions (EQ, NE, EXIST, ... long lost) back to TCC for evaluation. Rex, do you have any interest in such a thing?

 

[rconn]

Not too hard with a compiler; far from easy with an interpreter. I'd have to write a front-end preprocessor and evaluate everything twice (at least); I really don't think it's worth the trouble when the (rare) issues are easily worked around.

 

[vefatica]

Not too hard with a compiler; far from easy with an interpreter. I'd have to write a front-end preprocessor and evaluate everything twice (at least); I really don't think it's worth the trouble when the (rare) issues are easily worked around.

I was thinking more along these lines. You pass the complete conditional expression AS IS to a function (that I was considering writing). I parse its logical structure (and/or/xor/not ... probably built a tree of some sort). I evaluate the little pieces in some sensible order by passing them back to TCC for expansion and logical evaluation (TCC says just TRUE or FALSE). When I decide the truth value of the entire expression has been determined, I return with TRUE or FALSE possibly leaving parts of it unexpanded.

 

[rconn]

You can try if you want. The "simple" version in TCC is still a *lot* of code (at least 2K lines, not including all the supporting routines).