Evaluation of constant statements

[AlanTheBeast]

Code: Pascal  [Select][+][-]

1. CONST
2.   TFy = 0.95;
3.   TFx = 1 - TFy;
4.  

and later on

Code: Pascal  [Select][+][-]

1.    y := x * TFx;     //or
2.    y := TFx * x;
3.  

When I read this it irks me from an algebra POV....

I don't get that warm and fuzzy feeling that (1-TFy) is operated separately before (or after) the multiplication.

[KodeZwerg]

Code: Pascal  [Select][+][-]

1. CONST
2.   TFy = 0.95;
3.   TFx = 1 - TFy;

Code: Pascal  [Select][+][-]

1. CONST
2.   TFy = Double(0.95);
3.   TFx = Double(1 - TFy);

Thats how I would write such to have a proper type set.

[KodeZwerg]

I don't get that warm and fuzzy feeling that (1-TFy) is operated separately before (or after) the multiplication.

The constant will be "calculated" at the point when you set it, at least that's how it should work.

[Thaddy]

Code: Pascal  [Select][+][-]

1. CONST
2.   TFy = 0.95;
3.   TFx = 1 - TFy;
4.  

and later on

Code: Pascal  [Select][+][-]

1.    y := x * TFx;     //or
2.    y := TFx * x;
3.  

When I read this it irks me from an algebra POV....

I don't get that warm and fuzzy feeling that (1-TFy) is operated separately before (or after) the multiplication.

The compiler sticks to mathematical operator precedence. See the manual.
https://www.freepascal.org/docs-html/ref/ref.html#QQ2-151-184
The tables are listed in precedence order. Note ** is implemented by the programmer, it is listed at that position because ** is a special form of multiplication.

If you are not sure, you can indeed enclose a partial expression using ( and ) but carefully written code should not need that in all cases because of the above.

[440bx]

I don't get that warm and fuzzy feeling that (1-TFy) is operated separately before (or after) the multiplication.

true constants are evaluated at compile time, therefore the expression (1- TFy) doesn't exist past its declaration, what exists after its evaluation is its result.

[Thaddy]

true constants are evaluated at compile time, therefore the expression (1- TFy) doesn't exist past its declaration, what exists after its evaluation is its result.

Yes, but the precedence is equal at both compile time and runtime. 1-Tfy still relies on the same precedence even if it is already resolved at compile time. The evaluation order is the same both ways.

I interpreted his unease in that fashion, but indeed true const expressions are evaluated before compilation and replaced by a single constant. The same is true for typed constants in {$J-} mode also.

[AlanTheBeast]

Code: Pascal  [Select][+][-]

1. CONST
2.   TFy = 0.95;
3.   TFx = 1 - TFy;

Code: Pascal  [Select][+][-]

1. CONST
2.   TFy = Double(0.95);
3.   TFx = Double(1 - TFy);

Thats how I would write such to have a proper type set.

Well, I did have

Code: Pascal  [Select][+][-]

1.     TFy: Single = 0.95;
2.    Tfx: Single = 1 - TFy;
3.  

But that failed to compile.

But your solution works fine for me.  Never thought of a type cast in a constant statement.

Thanks.

[AlanTheBeast]

I don't get that warm and fuzzy feeling that (1-TFy) is operated separately before (or after) the multiplication.

true constants are evaluated at compile time, therefore the expression (1- TFy) doesn't exist past its declaration, what exists after its evaluation is its result.

What bothers me is that if I do a nice simple integer const set up such as:

Code: Pascal  [Select][+][-]

1. CONST
2.   A = 43;
3.   B = 72-A;

There is no compile time error.  I take the B as pre-computed and snug as a bug in rug.

Yet,

Code: Pascal  [Select][+][-]

1. CONST
2.     TFy: Single = 0.95;
3.    Tfx: Single = 1 - TFy;

Fails to achieve snug buggness.

IAC, KodeZwerg's solution is fine for my needs.

Thanks.

[Thaddy]

Indeed, I made a mistake. Type constants will throw an error.

[Arioch]

Code: Pascal  [Select][+][-]

1. {$J-}
2.  
3. const A: integer = 10;
4. const B = A + 2;  // unit1.pas(87,1) Error: Illegal expression
5.  

indeed, this compiles neither in Delphi nor in FPC.

Frankly, to me it looks like compiler defficiency. A bug wit hpriority too low to ever get fixed.

Unless they tacitly encourage hacks like

Code: Pascal  [Select][+][-]

1. {$J-}
2. const A: integer = 10;
3. var B: PInteger;
4. begin
5.   B := @A; B^ := 20;
6.  

[KodeZwerg]

IAC, KodeZwerg's solution is fine for my needs.
Thanks.

I am glad to help 

Never thought of a type cast in a constant statement.

Hmmm... I am not sure if I would call it a typecast, I would call it a typed constant 

[440bx]

Well, I did have

Code: Pascal  [Select][+][-]

1.     TFy: Single = 0.95;
2.    Tfx: Single = 1 - TFy;
3.  

But that failed to compile.

It doesn't compile because those are not true constants. The compiler cannot evaluate Tfx because it involves TFy which is NOT a constant (it is stored somewhere in the data segment instead of only existing in the compiler's parsing table(s)).

[AlanTheBeast]

Well, I did have

Code: Pascal  [Select][+][-]

1.     TFy: Single = 0.95;
2.    Tfx: Single = 1 - TFy;
3.  

But that failed to compile.

It doesn't compile because those are not true constants. The compiler cannot evaluate Tfx because it involves TFy which is NOT a constant (it is stored somewhere in the data segment instead of only existing in the compiler's parsing table(s)).

"true constant"?  What does that even mean?  A constant is a constant whether integer or float... is pi a constant?  Is it true?  False?

Syntactically dumb since it will evaluate integers correctly as I noted above, and it's not hyperdrive-rocketry to evaluate the expression as I wrote it.  I agree with Mr. Arioch that this appears to be a deficiency in the compiler.  Or at least an inconsistency.

I really don't see the issue with a constant being set float, esp. if the code specifies the data size as I did:      z: single = y*0.333;

I'm not a compiler expert to be sure, but allowing the integer constants to evaluate as I pointed out above, but not floating point seems to be a glaring inconsistency.

To whit, I'm not sure if the constant expression is inserted in the code - and therefore leaving me to wonder about the algebraic "sanity" of the whole thing.

Which is why people resort to hacks as Arioch suggests (not that I'd go there).

Anyway CodeZwerk's suggestion is fine and the universe did not break on compile or execution.

Never thought of a type cast in a constant statement.

Hmmm... I am not sure if I would call it a typecast, I would call it a typed constant 

 

Usually a typed constant looks (to little old me) like:
 x:   word = 33333;

Your slipping in the parentheses seems hacky...  but hacky-work is better than code that doesn't compile ---- !

[wp]

"true constant"?  What does that even mean?

This is a pecularity of the Pascal language, I think introduced in the old Turbo days:

Code: Pascal  [Select][+][-]

1. const
2.   a: Integer = 1;
3.  

This does not declare a constant, but a variable with initial value 1.

In current code, this is the same as

Code: Pascal  [Select][+][-]

1. var
2.   a: Integer = 1;
3.  

[440bx]

"true constant"?  What does that even mean?  A constant is a constant whether integer or float... is pi a constant?  Is it true?  False?

@wp answered your question but, more generally, anytime you declare a constant and specify its type (a typed constant) then you are actually declaring a _variable_.

Note that a typed constant is a different animal than a typecasted constant.  For instance:

Code: Pascal  [Select][+][-]

1. const
2.   a : integer = 1;  { this is a typed constant which means it is a _variable_ }
3.  
4.   b = integer(1);  { this is a true constant, _not_ a variable - note that a _type_ is _not_ specified }
5.  

Whether "a" above is writeable or not depends on the setting of the compiler directive "$WRITEABLECONST".  if ON then the compiler places "a" is in the writeable section (usually "data"), if OFF then the compiler places it in a read-only section (don't remember the name it uses at this time for those) but, what's important is that in _either_ case "a" represents an address somewhere in memory whereas a _true_ constant is a named value the compiler keeps in its tables and whenever it sees the name of the constant, it replaces it with the value it calculated for it.

HTH.