Hi, all,
Please don't hate me - while writting mirsad08.pas I came to this problem: line 14 with Boolean expression fails to compile (or I don't know Pascal syntax well enough). I reduced the example to the minimum at which problem still appears.
Changing ... AND (i<start OR i>endr) AND ... to ... AND ((i<start) OR (i<endr)) AND ... made it compile.
Here is the material: ---------------------------------------------------------------------------
more mirsad13.pas
PROGRAM boolexp(output); { Written by: Mirsad Todorovac Nov 2001; copying by GPL. ------------------------------------------------------------ Accidentally discovered that this didn't compile. }
VAR flag: Boolean; extra: Boolean; i, start, endr: Cardinal;
BEGIN
IF (NOT extra AND (i<start OR i>endr) AND (flag = true)) THEN {!thisline!} BEGIN extra := true; END;
END.
gpc mirsad13.pas
mirsad13.pas: In main program: mirsad13.pas:14: parse error before `>' mirsad13.pas:14: warning: expression used as a statement - value is ignored mirsad13.pas:14: warning: expression used as a statement - value is ignored mirsad13.pas:14: parse error before `)'
Best regards, Mirsad
-- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.
Mirsad Todorovac wrote:
Please don't hate me - while writting mirsad08.pas I came to this problem: line 14 with Boolean expression fails to compile (or I don't know Pascal syntax well enough).
I fear the latter (-; though it's a common problem). In Pascal, `or' etc. have higher precedence than `=', `>' etc.
Frank
Mirsad Todorovac wrote:
line 14 with Boolean expression fails to compile (or I don't know Pascal syntax well enough). I reduced the example to the minimum at which problem still appears.
Changing ... AND (i<start OR i>endr) AND ... to ... AND ((i<start) OR (i<endr)) AND ... made it compile.
Unfortunately, this is implied by standard pascal.
Extracted from a recent message on this list
------------------------------------------------------------------------- The Extended Pascal standard, Section 6.8.1 "Expressions, General" says:
"Operator precedences shall be according to five classes of operators as follows. The operator 'not' shall have the highest precedence, followed by the exponentiating-operators, followed by the multiplying-operators, the adding-operators and signs, and finally, with the lowest precedence, the relational-operators. Sequences of two or more operators of the same precedence shall be left associative."
Section 6.8.3.1, "Operators, General" defines the types of operators mentioned above:
exponentiating-operator = "**" | "pow"
multiplying-operator = "*" | "/" | "div" | "mod" | "and" | "and_then"
adding-operator = "+" | "-" | "><" | "or" | "or_else"
relational-operator = "=" | "<>" | "<" | ">" | "<=" | ">=" | "in" -------------------------------------------------------------------- OR has greater priority than < and >, and "start OR i" means nothing.
Maurice
Maurice Lombardi wrote:
OR has greater priority than < and >, and "start OR i" means nothing.
Well, actually it does (bitwise `or', BP extension), so `i < start or i' is still acceptable, but the following `>' is finally wrong (boolean expression on the left, integer on the right).
Frank
On Thu, 15 Nov 2001, Frank Heckenbach wrote:
Mirsad Todorovac wrote:
Please don't hate me - while writting mirsad08.pas I came to this problem: line 14 with Boolean expression fails to compile (or I don't know Pascal syntax well enough).
I fear the latter (-; though it's a common problem). In Pascal, `or' etc. have higher precedence than `=', `>' etc.
What the embarrasment :-( ... And at the time I knew it, now I remember - but it was in 1500 pascal lines of high-school graduation work ... Last 10 years I mostly did C ...
I blew it, Frank, what should I do to atone?
mirsad
-- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.
Mirsad Todorovac wrote:
On Thu, 15 Nov 2001, Frank Heckenbach wrote:
Mirsad Todorovac wrote:
Please don't hate me - while writting mirsad08.pas I came to this problem: line 14 with Boolean expression fails to compile (or I don't know Pascal syntax well enough).
I fear the latter (-; though it's a common problem). In Pascal, `or' etc. have higher precedence than `=', `>' etc.
What the embarrasment :-( ... And at the time I knew it, now I remember - but it was in 1500 pascal lines of high-school graduation work ... Last 10 years I mostly did C ...
I blew it, Frank, what should I do to atone?
Not necessary. Actually, this post has already helped, since Maurice's subsequent quoting of the standard led me to find some bugs in GPC with obscure cases like `True < False < True' and `0 in [1 .. 10] in [False]' which both are valid (and both should give True!) which I've just fixed. :-)
Frank
Mirsad Todorovac wrote:
Please don't hate me - while writting mirsad08.pas I came to this problem: line 14 with Boolean expression fails to compile (or I don't know Pascal syntax well enough). I reduced the example to the minimum at which problem still appears.
Changing ... AND (i<start OR i>endr) AND ... to ... AND ((i<start) OR (i<endr)) AND ... made it compile.
You are a victim of C-think. Pascal precedence is very simple: multiplication, addition, comparison. are the fundamental groups. When in doubt, parenthize. The results also read better.
CBFalconer wrote:
Mirsad Todorovac wrote:
Please don't hate me - while writting mirsad08.pas I came to this problem: line 14 with Boolean expression fails to compile (or I don't know Pascal syntax well enough). I reduced the example to the minimum at which problem still appears.
Changing ... AND (i<start OR i>endr) AND ... to ... AND ((i<start) OR (i<endr)) AND ... made it compile.
You are a victim of C-think. Pascal precedence is very simple: multiplication, addition, comparison. are the fundamental groups. When in doubt, parenthize. The results also read better.
In general I agree. But in this case I prefer C's precedence. `and' and `or' are applied to (in)equations in the vast majority of times, so they'd better have a precedence lower than comparisons, and you have to parenthesize the few cases where you actually want to compare the results of `and' or `or' (especially rare in non-Borland dialects which don't have bitwise `and' and `or').
(I know the argument considering `and' like a multiplication and `or' as an addition. But since mathematically the addition in GF(2) would be `xor', not `or', I don't give too much for it ...)
But we can't change it, anyway ...
Frank
-
CBFalconer -
Frank Heckenbach -
Maurice Lombardi -
Mirsad Todorovac