Hi,

According to the docs, the "is" operator is fourth level, the "and" is second level, so the "and" must be computed before the "is". But it seems fpc treats "is" and "and" as same level:

{$mode objfpc}
uses Classes;
var
  b: boolean;
  o: TObject;
begin
  // this compiles, but should fail:
  if o is TComponent and b then ;
  // this fails, correct
  if b and o is TComponent then ;
  // for completeness, this fails:
  if TComponent and b then ;
end.

The strange thing, is that the Delphi compiler works as fpc and the Delphi docs says the same as the fpc docs:
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Expressions_(Delphi)#Operator_Precedence

Mattias

Btw, there is a difference between fpc and delphi treating "is" and "or" precedence. The following compiles in fpc, but not in Delphi:

if b or o is TComponent then ;

Same with "xor".

This compiles in fpc and Delphi:
if o is TComponent or b then ;

It seems under Delphi "is", "and", "or", "xor" have the same precedence level and the Delphi docs are wrong.

Mattias

Hi, According to the docs, the "is" operator is fourth level, the "and" is second level, so the "and" must be computed before the "is".

Link:
https://www.freepascal.org/docs-html/ref/refch12.html

Mattias

Op 2018-12-08 om 20:38 schreef Mattias Gaertner via fpc-pascal:

According to the docs, the "is" operator is fourth level, the "and" is second level, so the "and" must be computed before the "is". But it seems fpc treats "is" and "and" as same level:

logical (boolean) vs bitwise AND difference?

I don't see where the bitwise should be involved here. There is no integer.
The docs do not mention a different precedence lvl for logical/bitwise "and".
It does not explain difference between "and" and "or".

Mattias

Hm.

In delphi, AS is second level, and 'is' is fourth level.

http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Expressions_(Delphi)

If FPC does this differently, then I think this is an incompatibility.

Because to the best of my knowledge, here isn't any difference in precedence, so there is nothing to explain.

It does not explain difference between "and" and "or".

Of course it does. See section on Logical operators

https://www.freepascal.org/docs-html/current/ref/refsu46.html

or boolean operators

https://www.freepascal.org/docs-html/current/ref/refsu47.html

I must confess it assumes that the reader knows what logical 'and' and 'or' means, but someone who does not know that will probably not read the docs. (although, he will also not understand "not" either and maybe read the docs...)

Michael.

What has "as" to do with this thread?

Yes, that's my point. Even if bitwise "and" would play a role here, the precedence would still be the same.

I looked at it, but I still don't understand.
Perhaps you can explain the examples I gave?

// compiles, but should fail:
if o is TComponent and b then ;
if o is TComponent or b then ;
// compiles in fpc, but not in Delphi:
if b or o is TComponent then ;
// does not compile, correct
if b and o is TComponent then ;

Mattias

It will compile if $BOOLEVAL is on the default (-) because the result can be determined without considering precedence, see:

https://www.freepascal.org/docs-html/prog/progsu4.html

Try it the other way round and it will fail:

o: TComponent;
if o is TObject

Martin.

Perhaps FPC treats "is" and "as" on the same level, it would explain the error ?

Agreed. It was Marco who brought this up ?

My hypothesis is that FPC treats 'is' and 'as' on level 2 (contrary to documentation). This is consistent with what you observe.

If 'is' is second level (i.e. the same as "as") then that would explain why it compiles, because the 'o is TComponent' will be evaluated first:

in the first line because evaluation happens from left to right, in the second line because 'is' takes precedence over 'or'.

// compiles in fpc, but not in Delphi: if b or o is TComponent then ;

Delphi is consistent with 'is' being on a lover level: "is" is lower level, so b or O is treated first.

Again, FPC's behaviour is consistent with treating 'is' on the same level as 'as': because 'is' takes precedence over 'or', you get no error.

// does not compile, correct if b and o is TComponent then ;

Indeed. (b and O) is evaluated first (left to right)

All is consistent with "is" and "as" being on the same level.

This is not how delphi does it.

So we adapt the documentation, or make the compiler delphi compatible.

Given that this has been in the compiler for years, I guess most people use brackets (I know I do)

Michael.

Op 2018-12-08 om 22:03 schreef Michael Van Canneyt:

My line of thought was the docs might mean bitwise there.

Because to the best of my knowledge, here isn't any difference in precedence, so there is nothing to explain.

And that was what my post was, checking that.

I'm more of the "more parenthesis never hurt anybody" school, so operator precedence beyond the normal mathematical is not my strong point.

Maybe clarify that?

I am of the same school. When in doubt, use parentheses. This is unambiguous.

Surely you are joking ?

The documentation is there to explain how the pascal language works, not how programming and computers in general work.

Michael.