;Test 1
if not x eqtype rva near
     display 'equals',13,10
else
    display 'differs',13,10
end if
;Test 2
if repeat '' eqtype times ''
  display 'equals',13,10
else
    display 'differs',13,10
end if
;Test 3
if repeat + 5 eqtype times dword
  display 'equals',13,10
else
    display 'differs',13,10
end if
;Test 4
if [+rva dword + x] eqtype ptr *
  display 'equals',13,10
else
    display 'differs',13,10
end if
;Test 5
if [-rva dword + x] eqtype ptr *
  display 'equals',13,10
else
    display 'differs',13,10
end if
;Test 6
if defined eqtype used
    display 'equals',13,10
else
    display 'differs',13,10
end if
;Test 7
if err eqtype rb
  display 'equals',13,10
else
    display 'differs',13,10
end if
;Test 8
if and eqtype neg
 display 'equals',13,10
else
    display 'differs',13,10
end if
;Test 9
if and eqtype not
 display 'equals',13,10
else
    display 'differs',13,10
end if
;Test 10
if not eqtype and
        display 'equals',13,10
else
    display 'differs',13,10
end if    

If you specify a subset of possible language constructions, then there should be an error when working with constructions outside of this subset.

Why does "if repeat" (Tests 2 and 3) compile at all? "repeat" is here an unexpected token under any conditions.

Now to the tests with "not" (Tests 9 and 10). Your list specifies instruction mnemonics as comparable tokens. So I expect also "not" to be comparable. But here you treat "not" as a beginning of a numeric expression and at the same time "and" (which can also be a numeric expression part) as an instruction. If you say, that that's because "and" is invalid at the beginning of a numeric expression, than why even parenthesizing "not" does not allow it to be compared as an instruction mnemonic? "not" would be in the same way invalid at the end of a numeric expression. For this reason also 9 should either return an error ("expected expression") or treat "not" as an instruction mnemonic.

And the last comment to complete expressions. Tests 4 and 5 are not quite good examples, but their only difference should show, there's a flaw with unary operators. For example, "[+not x]" is not considered as a valid address expression (in this case at least comparing it should return an error), but "[-not x]" is a valid expression.

There is no such rule. If you use constructions whose behavior is not defined by specification, it is exactly as it is: undefined behavior.

Assembler directives count among the "instruction mnemonic" category, so it is valid to use them in "eqtype" expression.

Yes, it seems that there is a bug, but it's not related to "eqtype" operation.

Quote:

There is no such rule. If you use constructions whose behavior is not defined by specification, it is exactly as it is: undefined behavior.

That's a very comfortable viewpoint, but there is such rule. Otherwise any typo should result in undefined behaviour. E.g., unintentional miv eax,ebx and you get a sysenter instead. That would be a horrible language.

And I'd like to ask one more question about eqtype which is however a little bit offtopic. Are relocatable labels also of the same type as other numeric expressions? I assume, you say yes. But my humble opinion, they should be a separate type. Because otherwise we don't have any way in fasm to determine, whether a label (or a numeric constant or even an expression) is relocatable, and usage rules for relocatable expressions are a lot more restrictive, than for other numeric expressions. Well... I could show situations, where it's absolutely necessary to distinguish relocatable expressions.

This happens with specifications of many languages, there is nothing unusual about it.

If we assumed than any construction that is not defined should signalize an error, the undocumented features would become the same as bugs.

But it is possible to add another logical expression operator for such purpose. Can you propose a name for it?

The "+ not x" bug has been fixed in 1.69.36 release.

fixed looks good and is the one I like the most, but I'm a little bit worried about how near to fix preprocessor directive is (or how could some people may attempt to test for fixed symbols ignoring that both belong to different stages and they don't know of each other).

if isRVA myAddress
  do something
else if not isRVA myAddress
  do something else
else
  WTF!
end if    

fixed looks good and is the one I like the most, but I'm a little bit worried about how near to fix preprocessor directive is (or how could some people may attempt to test for fixed symbols ignoring that both belong to different stages and they don't know of each other).

if : eqtype ''
     display 'equals',13,10
else
    display 'differs',13,10
end if
    

if <:> eqtype <''>    

if <: eqtype <''