Evaluation of constant statements

[MarkMLl]

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 ...).

I admit not having an attested source for that Xerox quote, the first time I saw it mentioned I think it was attributed to a FORTRAN manual which would put it in the 70s. However my point is not about the precision, but about the fact that it takes a certain type of nerd to appreciate that the statement isn't nonsensical, in the same way that it takes a certain type of nerd to appreciate that there is /some/ justification behind writeable consts.

Thinking back, I believe that I saw Xerox trying to flog those 8-bit systems no earlier than '85, i.e. roughly four years after 16-bit systems had abruptly become de rigeur. And even if there was a certain type of nerd that realised that they were still adequate for certain types of application, the kit was "on the wrong side of history" and got buried.

MarkMLl

[Thaddy]

Well, Mark,

Not in automotive for example.

[PascalDragon]

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.

Technically, of course that's possible (after all the compiler can do that with typed constants), but again we don't want multiple ways to achieve the same thing especially if there is no significant benefit of one over the other.

[MarkMLl]

Technically, of course that's possible (after all the compiler can do that with typed constants),

No, I don't think that would work: the variable would be initialised to the given value every time the function was entered, rather than persisting over function invocations.

The only realistic way would be to define a macro "staticvar" (or similar) to expand to "const".

but again we don't want multiple ways to achieve the same thing especially if there is no significant benefit of one over the other.

Oh come on, Sven, you can do better than that as a justification can't you? It's usually old-fool engineers like me who argue for things to be kept as-is in order to save resources (and look what that did for Y2K)... as an ambitious young CS type can't you at least come up with something plausible based on denotational semantics and its not being compatible with whatever fad is trendy this year?

The core team is always going on about things not being "in the spirit of Pascal", but can you show me anywhere that Wirth is on record saying that inconstant constants are a good idea?

Besides, you could continue the tradition of documenting it where nobody would find it...

MarkMLl

[Arioch]

> and look what that did for Y2K

and what? the end of the world was promised, and some few local upgrades were the actual outcomes.

To make example about resource scarcity that is no more, i'd rather complain that when you write to a file or delete it the old content is gone for good. That UNIX curse i am sure had hit every of us many times. As for dreaded Y2K, i think i was thrilled to be bitten by it - but was not. Surely someone was hurt, but hardly majority.

[Arioch]

after a variable definition (similar to what's done with "absolute") would be nice

absolute was not nice, it was ugly like hell.

Then, maybe it was intentionally ugly, to discourage people from using it. Then beign disfuncitonal is "a feature not a bug", but still hardly serves as a good exampele to follow.

var
  a, b: char;
  c, d: byte absolute a. absolute b;

Useful? For comparison, Soviet PDP-11 Pascal had it

var
  a, b: char;
  c origin a, d origin b: byte;

This positioning of syntax extension was resonable and useful. I repeat i am not sure that making this "break of convention" was good thing. Sometimes being intentionally disfunctional is a virtue;

And also i may make another case against "storage class" being coded as a directive AFTER the variable. It is a precedent of "threadvar" section,

[440bx]

absolute was not nice, it was ugly like hell.

since "absolute" is still part of Delphi and FPC, it is not a "was" it is an "is".  In addition to that, there is nothing ugly about it.

Then, maybe it was intentionally ugly, to discourage people from using it.

Like any other feature, it can make code easier and cleaner (when used correctly) and, I suppose it can be really ugly when misused.  People should be encouraged to use it correctly.

And also i may make another case against "storage class" being coded as a directive AFTER the variable. It is a precedent of "threadvar" section,

It would not be a directive, it would be a storage modifier. 

The point was and, still is, that it would be reasonably simple to provide a clean (not to mention logically coherent") alternative to the "writeable constant" contradiction.   Unfortunately, since it is quite clear that FPC's developers have little to no interest to providing an alternative, the "writeable constant"(s) will remain the only game in town for static variables.

and writeable constants go on...

[Arioch]

In addition to that, there is nothing ugly about it.

So how i use it to specify addresses to the variables, declared in the same block ?

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

1. var
2.   a, b: Utf32char;
3.   c, d: array [0..3] of byte absolute ???;
4.  

c should be mapped to a, d should be mapped to b. They should be declared in one declaration, as they must share the datatype. Using workarounds, like adding boilerplate of creating a named type when it is not needed, would only stress how the syntax was broken by design, being disfunctional without workarounds.

The address of a variable is NOT part of datatype. Making variable address part of datatype was... very wrong, if you don't like ugly.

It would not be a directive, it would be a storage modifier.

Whatever the name.
There already is "threadvar", and it is not being put after the variable name. Implementing a similar feature with different syntax pattern would not be nice.

the "writeable constant"(s) will remain the only game in town for static variables.

Not quite.
There are class var. There are variables in unit's implementation sections.
Both are global lifetime variables with local scope.

In the end it seems to be about Pascal/Delphi not having explicit language-level namespaces, as C++ added.

and writeable constants go on...

They do as long as need to compile legacy TP/Delphi code is there.
I do not think new Delphi code uses it a lot, i believe it is esoteric quirk for modern programmers in any Pascal flavour.

I guess anyone can ask Heilsberg why did he name them that way. Maybe it was a quick hack or even bug, that gained wide use before anyone knew and had to be documented retroactively?..

[MarkMLl]

I guess anyone can ask Heilsberg why did he name them that way. Maybe it was a quick hack or even bug, that gained wide use before anyone knew and had to be documented retroactively?..

I'm too lazy to investigate precisely what version of TP introduced it, but If it were in the DOS era I think there's a real possibility that he was under a significant amount of pressure to minimise the size of the core compiler since the available 600ish K also had to contain- at an absolute minimum- the parse tree of the unit being compiled plus all of the symbol tables etc.

Which is really no justification for not providing an alternative, since it's unlikely that FPC will run on anything that constrained.

MarkMLl

[Arioch]

pressure to minimise the size of the core compiler since the available 600ish K

Not enough. If the quest was to avoid introducing new keywords (which Wirth seemed to emphasize BTW), he could just make them "initialized variable" syntax with the same compiler size.

I just suppose the term of "writeble constant" did not sound so heretic back then, when terms themselves were only being invented, as it is now. And probably "initialized variable" back theb sounded equally wrong.

[440bx]

So how i use it to specify addresses to the variables, declared in the same block ?

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

1. var
2.   a, b: Utf32char;
3.   c, d: array [0..3] of byte absolute ???;
4.  

c should be mapped to a, d should be mapped to b. They should be declared in one declaration, as they must share the datatype. Using workarounds, like adding boilerplate of creating a named type when it is not needed, would only stress how the syntax was broken by design, being disfunctional without workarounds.

"absolute" is used to tell the compiler to place a variable at the same address as another variable, basically one variable overlays another.  That's what "absolute" is for.  The example you provided is senseless.  There is no need to declare two overlays ("c" and "d" in your example above" of the same type) on top of another variable.  The point of overlaying is to use different types otherwise it makes no sense to create the overlay. In your example, the sensible thing would be to declare something along the lines of:

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

1. c : array[0..3] of byte absolute a;

The address of a variable is NOT part of datatype. Making variable address part of datatype was... very wrong, if you don't like ugly.

As you stated, the address of a variable is not part of its datatype but, the address of a variable is definitely part of its definition, which is its declaration and, adding "absolute" declares the address of the variable, in this case, the address of the "new" variable is the address of a previously declared variable, which makes that "new" variable be overlaid on top of the previously defined variable (at its address.)

There already is "threadvar", and it is not being put after the variable name. Implementing a similar feature with different syntax pattern would not be nice.

Sure, it could be done by using a keyword such as "static" as a "prefix" (instead of threadvar.) There is more than one way to skin a cat.

There are class var. There are variables in unit's implementation sections.
Both are global lifetime variables with local scope.

That's a completely different thing and of no help whatsoever for any function/procedure that is not part of a class.

In the end it seems to be about Pascal/Delphi not having explicit language-level namespaces, as C++ added.

Having namespaces doesn't provide the functionality static variables provide which is what writeable constant does.

I do not think new Delphi code uses it a lot, i believe it is esoteric quirk for modern programmers in any Pascal flavour.

Not so esoteric.  It is not all that uncommon to have to calculate a complex, time consuming expression inside a loop which, after being calculated, remains constant inside the loop.  In those cases a static variable is the desirable solution... compute once, re-use the result in all remaining iterations.

I guess anyone can ask Heilsberg why did he name them that way. Maybe it was a quick hack or even bug, that gained wide use before anyone knew and had to be documented retroactively?..

The most likely reason is that they didn't want to allow initialized variables in functions/procedures because that requires the compiler to generate code to initialize those variables every time the function/procedure is entered, which in turn would have required changes in the code generator and as MarkMLI pointed out, that would have consumed precious memory (precious in those days.)  In other words, allowing initialized variables required a fair number of changes in the compiler.   Not so with constants, just add a little bit of code in the part of the compiler that parses constants and, a new "global" variable with the same scope as the constant declaration is born.  Quick and easy hack... no changes required in the code generator.

[MarkMLl]

Not enough. If the quest was to avoid introducing new keywords (which Wirth seemed to emphasize BTW), he could just make them "initialized variable" syntax with the same compiler size.

There was little alternative in the early days, since the industry was just moving from 6- to 7-bit character representation and things like braces were not always available. In addition, Wirth was trying to build on ALGOL-60 (via his ALGOL-W) even if he intentionally broke backwards compatibility in some areas. Hence

I just suppose the term of "writeble constant" did not sound so heretic back then, when terms themselves were only being invented, as it is now. And probably "initialized variable" back theb sounded equally wrong.

Just a mo, I think that's wrong: ALGOL had "own" as a declaration qualifier which had /exactly/ the effect we're talking about. While it's inconceivable that Wirth didn't know about that, it's entirely plausible that nobody at Borland (and predecessor/successor companies) had that level of experience.

Slightly later: https://www.osti.gov/servlets/purl/4020495

The value of a variable is lost after exit from the block in which this variable is declared. There are some cases where this is undesirable, and ALGOL provides for a special class of local variables, the so-called own variables, which retain their identity throughout the program.

A simple variable or an array is declared own by preceding the corresponding declaration with the symbol own.

Example:

own real x, y;
own integer array a[1:10], b, c[4 :17];

...noting that ALGOL's declaration order is more like C than Pascal.

That demonstrates that ALGOL-60 did have variables that had local scope but static lifetime, but since the declaration didn't have an initial value it's not /exactly/ the same as Pascal's "inconstant constants" and it's noted somewhere that one had to be careful assuming any particular initial value.

But this still provided an entirely adequate precedent for somebody to follow, had they known about it.

MarkMLl

[Arioch]

So how i use it to specify addresses to the variables, declared in the same block ?

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

1. var
2.   a, b: Utf32char;
3.   c, d: array [0..3] of byte absolute ???;
4.  

c should be mapped to a, d should be mapped to b. They should be declared in one declaration, as they must share the datatype. Using workarounds, like adding boilerplate of creating a named type when it is not needed, would only stress how the syntax was broken by design, being disfunctional without workarounds.

That's what "absolute" is for.

Thank you i know. Just the syntax is broken, making simple things impossible without falling back to workarounds.

The example you provided is senseless.

No it is not. It has perfect sense.

I repeat: c should be mapped to a, d should be mapped to b. They should be declared in one declaration, as they must share the datatype. Using workarounds should not be needed.

There is no need to declare two overlays ("c" and "d" in your example above" of the same type) on top of another variable.

You did not read what you quoted, did you?  Okay, i repeat yet again. There is to be no overlaying the same variable.

Quote: c should be mapped to a, d should be mapped to b.

In your example, the sensible thing would be to declare something along the lines of:

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

1. c : array[0..3] of byte absolute a;

You did not read what you quoted, did you?  Okay, i repeat yet again.

Quote: They should be declared in one declaration, as they must share the datatype.

The address of a variable is NOT part of datatype. Making variable address part of datatype was... very wrong, if you don't like ugly.

As you stated, the address of a variable is not part of its datatype but, the address of a variable is definitely part of its definition.[/quote]

No. The address of the variable became part of the datatype definition put inside variable declaration (not merely definition).

Otherwise, if that is not part of datatype definition, show me how to make two variables declared together be mapped to differen addresses.

Code: [Select]

var  c, d: array [0..3] of byte absolute ???;
The proper syntax design, putting attributes where they belong, allows it naturally.

Code: [Select]

var  c origin a, d origin b: array [0..3] of byte;

There already is "threadvar", and it is not being put after the variable name. Implementing a similar feature with different syntax pattern would not be nice.

Sure, it could be done by using a keyword such as "static" as a "prefix" (instead of threadvar.) There is more than one way to skin a cat.

Having two ways is rarel good - it usually shows that one of the ways is worse and a way better had to be added.

For example, putting overrode variable address after the related variable name was a good way to skin a cat.
And making overrode address part of the datatype, which in Pascal is intended to be shared by several variables, was bad way to skin a cat.
But maybe intentionally bad.

[MarkMLl]

You did not read what you quoted, did you?  Okay, i repeat yet again.

Stop please. There's an FPC historical/cultural problem here which has been simmering for some years, which is allocating and assigning values to tuples.

Everybody- who's been here for any length of time- knows that it's an issue. So I really /don't/ think that extending it to _absolute_ is going to help anybody.

MarkMLl

[Arioch]

...allocating and assigning values to tuples.
that extending it to _absolute_ is going to help anybody.

there are 3 folllowups here. But i'd chose one: your comparison with unpacking/structural assignment just indirectly reinforced my own gut feeling, that "Absolute" design was intentionally made alien to Pascal and packed with unneeded burdens to its use, to make that dangerous feature be used as rare as possible.