v 4.80 Beta: Incorrect syntax in expression accepted

[sasa72]

Following code is correct by compiler:

Code: Select all

var 
  rr,y : real;
  i: byte;
begin
  y:=1;

  rr:=0;
  for i:=1 to 10 do
  begin
    rr:= rr+ (1./i * y=(y+1)*i);
    y:=(y+1)*i;
  end;
  
end.

This perhaps is another compromise and implicit typecasting (Boolean to Integer/Float). Otherwise, this is not allowed in pascal syntax.

[zristic]

Yes, it is a compromise.
y=(y+1) is a boolean expression and it should return false (zero).
Thanks for notifying this.

[zristic]

After the second look, i see it is more complicated due to operators precedence...
But still the operator "=" will perform boolean in this case.

[sasa72]

Including other boolean operators in expression, issue tends to become very complicated during implicit typecasting and code optimization. Assume following:

rr:= rr+ (1./i * y=(y+1)*i and odd(i));

What path compiler will choose:

( y=(y+1)*i ) and odd(i)

or

y= ( (y+1)*i ) and odd(i)

If we know "and" and "or" can be used with Boolean and bytes, thing become much more complicated and it is hardly to predict compiler behavior. As well, we know that priority operators with Booleans in Pascal are bit different than in mathematic...

Those are few main reasons why forcing implicit typecasting makes more trouble than usefulness. As well, compilers expression evaluator must be very hard to maintenance.

Thus I would suggest that compiler rise error and stop compilation. I can't imagine many cases where mixing Booleans and integers/float gives advantage in code optimization.

I would also suggest a general compiler option: "Implicit typecasting allowed" or similar. False by default.

[zristic]

It will choose the second solution.
Well, you are right, but also there is another part of the story which is support. In our experience it is better to solve as much as possible before throwing an error. This is how beginners get out of trouble easily, but the experts (such as you) are aware of the inconsistence.
It's the price of the compromise.

[sasa72]

This perhaps is not very important for trivial projects. However, for more complex ones such as for medical equipment, guided/autonomous robots (e.g. industrial robots, small airplanes&helicopters), even after detail debugging undiscovered small syntax error in sense of rigid Pascal syntax, could be fatal. If we assume these projects makes no amateurs, at least mentioned option would be precious.