Evaluation of constant statements

[Thaddy]

Assignable typed consts ({$J+} are only useful inside functions, procedures and methods.
That way you can maintain state, for example. Globals should simply be var.
This predates Pascal OOP and can be very useful.

[AlanTheBeast]

If I need a function to track something pending its return next invocation, that _______ VARIABLE _______ is properly declared in Global scope for that unit or program.

But the problem there is that that would make it globally visible, which you do not want.

It's an absolutely horrid choice of syntax, partially overlapping variables initialised at declaration: same visibility, different lifetime.

MarkMLl

If such a private non-volatile local to the function variable is (really) needed then create a storage section for such:


Function IRecallACleanerPascal(x:real):boolean;
CONST
  B=2;
NONVOLATILE
  R=0;
VAR

[MarkMLl]

If such a private non-volatile local to the function variable is (really) needed then create a storage section for such:

Code: [Select]

Function IRecallACleanerPascal(x:real):boolean;
CONST
  B=2;
NONVOLATILE
  R=0;


Since when's that been valid Pascal?

Besides which, if you start talking about nonvolatile you'll have a swarm of people objecting that the value isn't preserved when they rerun the program.

MarkMLl

[PascalDragon]

If I need a function to track something pending its return next invocation, that _______ VARIABLE _______ is properly declared in Global scope for that unit or program.

But the problem there is that that would make it globally visible, which you do not want.

It's an absolutely horrid choice of syntax, partially overlapping variables initialised at declaration: same visibility, different lifetime.

MarkMLl

If such a private non-volatile local to the function variable is (really) needed then create a storage section for such:


Function IRecallACleanerPascal(x:real):boolean;
CONST
  B=2;
NONVOLATILE
  R=0;
VAR

The existing syntax with typed constants is required for compatibility with TP and Delphi anyway and we don't like to have multiple syntaxes that allow the same functionality without any significant benefit of one over the other, so no, something like this won't be done.

[MarkMLl]

The existing syntax with typed constants is required for compatibility with TP and Delphi anyway and we don't like to have multiple syntaxes that allow the same functionality without any significant benefit of one over the other, so no, something like this won't be done.

Leaving aside all discussion as to whether the terminology should be fixed, could an initialised variable be used for this with a storage attribute that put it in the global area?

I suppose not, since the function would still set it to the initial value every time.

Anybody who dislikes the status quo that strongly could perhaps use a macro to expand STATIC as CONST...

MarkMLl

[440bx]

The existing syntax with typed constants is required for compatibility with TP and Delphi anyway and we don't like to have multiple syntaxes that allow the same functionality without any significant benefit of one over the other, so no, something like this won't be done.

That's completely reasonable, compatibility with TP and Delphi leaves little choice but to support the "writeable constants" contradiction.  It is also reasonable not to be enthusiastic about having more than one syntactic construct to do the same thing.

All that said, a "writeable constant" is nothing short than an embarrassment for the Pascal language. Maybe something like allowing a keyword, such as "static" after a variable definition (similar to what's done with "absolute") would be nice because it would spare Pascal users from having to explain a ridiculous decision made decades ago by a company that had no problem implementing a sordid gimmick to make a quick buck.

[MarkMLl]

That's completely reasonable, compatibility with TP and Delphi leaves little choice but to support the "writeable constants" contradiction.  It is also reasonable not to be enthusiastic about having more than one syntactic construct to do the same thing.

...in exactly the same way that Xerox's comment that a good example of a manifest constant was something like

Code: [Select]

const pi=3.14159;

"in case the value of Pi should change".

Both make perfectly good sense to people who understand the history and value its quirks, but they leave subsequent generations at best amused by their quaintness and at worst dismissive and hostile.

MarkMLl

[AlanTheBeast]

If such a private non-volatile local to the function variable is (really) needed then create a storage section for such:

Code: [Select]

Function IRecallACleanerPascal(x:real):boolean;
CONST
  B=2;
NONVOLATILE
  R=0;


Since when's that been valid Pascal?

Besides which, if you start talking about nonvolatile you'll have a swarm of people objecting that the value isn't preserved when they rerun the program.\

I never said that was valid (or at least current) Pascal.  OTOH all sorts of mysterious crud have crept in via Borland, Delphi, et al. such as function "Result :="

Nonvolatile in a running program context shouldn't be a mystery - esp. if clearly defined.

[Thaddy]

@Mark
Simple math again. Pi is - for now - an irrational number, so its approximation can change.
e.g. 22/7 or 355/113. Xerox was right to issue that remark.
Since the proof is deterministic this CAN change. (highly unlikely, though)

[AlanTheBeast]

That's completely reasonable, compatibility with TP and Delphi leaves little choice but to support the "writeable constants" contradiction.  It is also reasonable not to be enthusiastic about having more than one syntactic construct to do the same thing.

...in exactly the same way that Xerox's comment that a good example of a manifest constant was something like

Code: [Select]

const pi=3.14159;

"in case the value of Pi should change".

Both make perfectly good sense to people who understand the history and value its quirks, but they leave subsequent generations at best amused by their quaintness and at worst dismissive and hostile.

Many people are useless at trig ... at least it's not as bad as the State of Indiana bill #246 in 1897.

Old trick is Pi := 4 *arctan(1); for systems that don't provide Pi as a constant.

GPS ICD-200 is adamant that Pi be a fixed, truncated rounded value of 3.1415926535898.    (period for emphasis in the spec).  This applies to some deeper signal processing issues related to antennas and signal phase and such - Not for actual navigation functions.

[440bx]

@Mark
Simple math again. Pi is - for now - an irrational number, so its approximation can change.

That's going to be a very, very long "now".  Pi is not only irrational, it has been proven to be transcendental.

That said, there are as many possible approximations of Pi as there are digits in Pi   Pi has at least as many approximations as there have been and there will be "now"(s) in time.  (it's a "large" number... <chuckle>)

[AlanTheBeast]

The existing syntax with typed constants is required for compatibility with TP and Delphi anyway and we don't like to have multiple syntaxes that allow the same functionality without any significant benefit of one over the other, so no, something like this won't be done.

I'm shocked!  Shocked I tell you!

Not really.  Still recovering from this "new" thing that I should have known about.  As I said earlier I might be tempted to take advantage of it, but see no actual need to abuse it.

[AlanTheBeast]

@Mark
Simple math again. Pi is - for now - an irrational number, so its approximation can change.

That's going to be a very, very long "now".  Pi is not only irrational, it has been proven to be transcendental.

That said, there are as many possible approximations of Pi as there are digits in Pi   Pi has at least as many approximations as there have been and there will be "now"(s) in time.  (it's a "large" number... <chuckle>)

How about printing 1.7 km worth (1M digits) ?
https://www.youtube.com/watch?v=0r3cEKZiLmg&ab_channel=Numberphile

[MarkMLl]

Simple math again. Pi is - for now - an irrational number, so its approximation can change.
e.g. 22/7 or 355/113. Xerox was right to issue that remark.
Since the proof is deterministic this CAN change. (highly unlikely, though)

Yes: I know that, you know that, and it's even possible that Xerox knew that; more to the point, a new architecture of computers might have made it worth adding a few more digits to the definition. But it takes a particular type of nerd to appreciate that, and the majority is content to mock what they consider to be an absurdity.

Similarly, it takes a particular type of nerd to appreciate- and even minimally care about- the roots that underlie the semantic absurdity that is a writable constant. The majority is content to mock what they consider to be an absurdity.

Now it's not widely appreciated, but at the same time that Xerox PARC was contributing massively important R&D to the overall computing community, Xerox still had frontline salesmen trying to flog 8-bit computers into business: see for example https://en.wikipedia.org/wiki/Xerox_820 . Xerox is, by now, effectively buried: as is Borland and its successor companies and their products. I'd rather not see that happen to FPC/Lazarus.

MarkMLl

[AlanTheBeast]

Simple math again. Pi is - for now - an irrational number, so its approximation can change.
e.g. 22/7 or 355/113. Xerox was right to issue that remark.
Since the proof is deterministic this CAN change. (highly unlikely, though)

Yes: I know that, you know that, and it's even possible that Xerox knew that; more to the point, a new architecture of computers might have made it worth adding a few more digits to the definition. But it takes a particular type of nerd to appreciate that, and the majority is content to mock what they consider to be an absurdity.

If you consider that into the 70's engineers were still often using slide rules for all manner of computation, and not especially interested in more than 3 significant digits for a large number of calculations, then any reasonable approximation of Pi is not all that absurd.  To be sure the etched position of Pi on a slide rule was fine and accurately made, but in practice digits fell off the edge of the table pretty fast.  A lot of bridges, aircraft, electronics and so on were well designed from that (mainly due to various margins of course ...).

Indeed the "lowliest" approximation (I believe) is 22/7 which has an error of about 4/100ths of 1% of Pi ... so would meet the needs of most calculations for casual use - as to 355/113, well ... -0.000008491% ...

"Ladies and Gentlemen, this is your Captain speaking, we'll soon reach our cruising altitude of 35,000 feet and because this is an American designed aircraft it will not shatter due to fatigue cracking like that British airliner you've heard about.  Square windows?  Everyone knows you can't square a circle."