CBFalconer wrote:
No, even in 7185 constants have a type. It is derived from their definition.
Yes, under "typed constants" I normally understand constants whose type is explicitly declared. EP knows this only for structured types, BP for any type, and the syntax is different, but that's not the main issue.
The above would always be an integer constant. They are just not alterable a la TP.
That's another issue (and I dislike it as much as you do). I assume here that the "external constants" are really constant and never altered by the Pascal code nor by the external code.
TYPE anindex = 1..maxindex; myarray = array[anindex] OF whatever;
VAR array1, array2 : myarray;
and think about how you can test assignment compatability at compile time,
Assignment compatibility (as far as I understand it) is no problem. array1 and array2 are of the same type and therefore compatible, and any other array type is not compatible. Remember that two identical looking structured type declarations are not compatible in Pascal, e.g.:
var a: array [1 .. 10] of Integer; b: array [1 .. 10] of Integer; [...] a := b { WRONG }
True, although I always forget that. Back in the days of the first standards there were long arguments about the definition of assignment compatibility. The other attack is that they are compatible if all their components are compatible (and declared in the same order for records).
I'm glad they chose the other route. Makes type-checking quite a bit easier and, more importantly, possible at compile-time, even in such complex situations.
That is the area where efficiencies come up. The more that can be done at compile time the more efficient you can make the final program. Use of tight subranges helps. The compiler can often deduce the possible range, and skip the check. In the above, if the index variable is of type anindex, the compiler knows it is valid, and need generate no checking code. This sort of thing cuts the checking overhead down by a large factor.
[...]
Yes it would, but that involves making sure that code is exercized in testing. I hate the very idea.
[...]
Same comment about making sure the code is exercized. I for one don't want to give up the warm fuzzy from compile time checks.
All true. Just don't use "external constants" then. I mean, they're not meant to replace ordinary constants, only for special situations where the alternative (having them as an external variable) would be even worse.
You basically lose all the advantages of doing things at compile-time when you use them, but you still keep the safety that some code doesn't accidentally modify the constant (unlike BP's "constants"!).
If maxindex is a variable, then it can be external, but we can't declare the anindex and myarray types.
Yes, we can (i.e., according to 10206). GPC currently doesn't allow it at global level (because it allocates static storage for global variables which is not suitable in these cases; we'll have to fix this sometime), but it does locally.
Boggles my mind. I tend to think about 'how do we verify this' rather than 'how do we implement this'.
AFAICS, the only thing we need (besides the range-checks done at runtime) is a check if the actual array size is positive (which GPC currently doesn't check, but should). Again, type compatibility should be rather easy thanks to the strict rules.
Frank