The problem is as follows, for the compiler to use the value assigned to px or any pointer for that matter, it has to dereference px at compile time. dereferencing a pointer is a runtime operation, not a compile time one.
During compilation there is no pointer, and no memory address for it. At this time the compiler has a structure that describes this variable, its type, local or global, and its
initial value if any. The compiler does not need to dereference any pointer, it just passes that same initial value to the structure that represents the array.
It's not confusing because in one case it's a constant (@x) and in the other it's a variable (px^).
In run-time code, yes. @x is a constant, and px^ is a variable. In compile time within the initialization section, no, both are constants.
It isn't initialized with constants in both cases. In the case of px, it is initialized with the value of a variable and no compiler is going to dereference the value of a pointer at compile time even if the value of the pointer happens to be known.
As I said above, no dereferencing is going to happen, nor needed at compile time. Just passing the value from one structure to the other one.
There are definitely some cases where it would be impossible, e.g, when the pointer isn't initialized. At runtime, if a programmer dereferences a nil pointer, that causes an access violation. To have a compiler dereference pointers at compile time, it would have to interpret the code as it is compiling because if pointer dereferencing is allowed at compile time then it has to support dereference chains where one pointer has the value of another which has the value of another and so on until it finds the "root pointer" that has (hopefully) been assigned a value. That's a nightmare for a compiler (not to mention for the programmer who has to write that compiler.)
Again, no dereferencing is needed during compile time. Dereferencing is a run-time concept.
In addition to the above, there is a semantic problem in allowing an array element to be a variable. The statement:arr: ArrayOfPReal = (@x, px);
states that arr[1] is px, therefore whatever value px has at anytime should also be the value of arr[1]. IOW, at runtime when px is assigned a new value then arr[1] should have that same value since arr[1] is px.
That's the semantic meaning of that declaration.
I don't think so, because this is not how you get this meaning in Pascal.
Absolute is the keyword used to provide this meaning. It would be more along:
var
arr: array[0..1] of pinteger;
x: pinteger absolute arr[1];