Problem may in lua-parser/parser.lua:binaryOp

[andremm]

Problem may in lua-parser/parser.lua:binaryOp

[hnes]

Sorry for that I had make a mistake. The 2nd solution is not right at all because for floating-point comparisons (x < y) is not the same as not (x >= y) in the presence of NaNs.

Proof:

#lua
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> z = 0/0
> =z
-nan
> return z>z
false
> return z<z
false
> return z>=z
false
> return not (z>=z)
true
>

So that seems the 1st solution is the only choice after then :(

[andremm]

The function binaryOp is coded that way because the parser reproduces the same behavior of the Lua parser itself, as it is expressed by the Lua manual: A comparison a > b is translated to b < a and a >= b is translated to b <= a.

[hnes]

Hi Andre, thanks for your reply, but I still insist on my idea.

A comparison a > b is translated to b < a and a >= b is translated to b <= a.>

I approve this statement but that is not mean you could simply swap them in the AST generating phase. I think you may actually misunderstand it because this kinda AST lt transformation is fatally wrong in semantic which will lead the wrong result of computation later based on the AST tree.

For example:

$ cat t.lua
gl_f_ct = 0

function f()
    if gl_f_ct <= 0 then
        gl_f_ct=1
        return 1000
    end
    return -1000
end

print( f("1st call") > f("2nd call") ) --> in lua-parser's ast: lt f("2nd call") f("1st call")  | wrong
gl_f_ct = 0
print( f("1st call") < f("2nd call") ) --> in lua-parser's ast: lt f("1st call") f("2nd call")  | right
$ lua t.lua
true
false

But after execution in the AST lua-parser generated, it's result is:

$ lua-parser gen_ast_and_execute_it.lua t.lua
fasle
false

This kinda of error is due to the lt transformation had changed the sub-AST tree's execution order mistakenly.

[hnes]

    [2] = {
      [tag] = Op
      [pos] = 8
      [1] = lt
      [2] = {
        [tag] = Call
        [pos] = 24
        [1] = {
          [tag] = Id
          [pos] = 24
          [1] = f
        }
        [2] = {
          [tag] = String
          [pos] = 26
          [1] = 2nd call     <-- wrong
        }
      }
      [3] = {
        [tag] = Call
        [pos] = 8
        [1] = {
          [tag] = Id
          [pos] = 8
          [1] = f
        }
        [2] = {
          [tag] = String
          [pos] = 10
          [1] = 1st calll     <-- wrong
        }
      }
    }

If you only have this kinda AST tree which may had been with some lt transformation, you will never know which function should execute first without making some mistake in semantic.

[andremm]

You have a good point: we cannot assume that values are always evaluated or never have collateral effects before applying relational operators.

It looks like Metalua has the same issue, as

local mlc = require "metalua.compiler".new()

local test = [[
gl_f_ct = 0

function f()
    if gl_f_ct <= 0 then
        gl_f_ct=1
        return 1000
    end
    return -1000
end

print( f("1st call") > f("2nd call") )
gl_f_ct = 0
print( f("1st call") < f("2nd call") )
]]

local ast = mlc:src_to_ast(test)

local f = mlc:ast_to_function(ast)

f()

produces the same error.

I just pushed a commit that adds all relational operators to the AST. Can you please check whether this issue is solved?

[hnes]

Yes, Metalua does have the same issue, but it seems Metalua has no maintenance anymore for a quite long time.

Thanks Andre for your time and good patience :)

( I have checked and tested the commit and it works just as fine as it could possible being :D )

[andremm]

Thanks Andre for your time and good patience :)

Thank you for the bug report!

( I have checked and tested the commit and it works just as fine as it could > possible being :D )

Sounds great! I'm closing this issue then.