operators are not applyed to a function's return value

[abenkovskii]

[Dunbaratu]

Okay this is truly weird.

The code produced by print truth(). is this:

1/test                  5:1   0012 push $<argstart> 
1/test                  5:10  0013 push $<argstart> 
1/test                  5:10  0014 call $truth*
1/test                  5:10  0015 call print() 
1/test                  5:10  0016 pop 

The code produced by print not truth(). is this:

1/test                  7:1   0017 push $<argstart> 
1/test                  7:14  0018 push $<argstart> 
1/test                  7:14  0019 call $truth*
1/test                  7:14  0020 call print() 
1/test                  7:14  0021 pop 

Literally identical. The "not" operator is being completely and utterly ignored by the compiler somehow in this case.

Interestingly, changing the example to print not (truth()). works:

1/test                  7:1   0017 push $<argstart> 
1/test                  7:14  0018 push $<argstart> 
1/test                  7:14  0019 call $truth*
1/test                  7:14  0020 not
1/test                  7:14  0021 call print() 
1/test                  7:14  0022 pop 

The insertion of the opcode: 0020 not
is what's missing entirely from the first examples.

No idea why. It's NOT order of operations, because this: print (not truth)(). produces an error as it should ( "not truth" isn't a function, so you can't append the () to it.).

[Dunbaratu]

I pulled up TinyPg to see what the parse tree really looks like for print not truth(). vs print truth()., just to verify that the parser sees them as different, and it does:

print truth() is:

instruction
    print_stmt
        PRINT 'print'
        expr
            and_expr
                compare_expr
                    arith_expr
                        multdiv_expr
                            factor
                                suffix
                                    suffix_term
                                        atom
                                            IDENTIFIER 'truth'
                                        suffixterm_trailer
                                            function_trailer
                                                BRACKETOPEN '('
                                                BRACKETCLOSE ')'
        EOI '.'

print not truth() is:

instruction
    print_stmt
        PRINT 'print'
        expr
            and_expr
                compare_expr
                    arith_expr
                        multdiv_expr
                            factor
                                suffix
                                    suffix_term
                                        atom
                                            NOT 'not'
                                            IDENTIFIER 'truth'
                                        suffixterm_trailer
                                            function_trailer
                                                BRACKETOPEN '('
                                                BRACKETCLOSE ')'
        EOI '.'

So the NOT does parse but... the compiler isn't noticing it... garrg.

[Dunbaratu]

ahhhhhhh crud.
I see why it's wrong:

The same problem happens with '-', when used as unary operator to negate a value, rather than a binary operator for subtraction.

i.e. like so: print - myfunc().
All the unary operators have the same problem because of their parse precidence.

They have tighter precedence than than the function_trailer does.

Also, colons for suffixes are the same way:

set foo to list().
print foo:empty.
True
print not foo:empty.
Cannot boolean-not ListValue
At interpreter history, line 4
print not foo:empty.
          ^

It tried to do the NOT first, and THEN the colon operator.

I am hoping the fix is just purely moving the unary operators out of the atom level of the parser and putting them a bit higher up.