Gale Paeper wrote:
As Adriaan indicates, there are some differences in terminology in use between GPC and Macintosh Pascal dialects' compiler directive descriptions. From the GPC documentation, 6.9 Compiler Directives And The Preprocessor:
"BPÂs conditional definitions (Â{$define Foo}Â) go into another name space than the programÂs definitions. Therefore you can define conditionals and check them via {$ifdef Foo}, but the program will not see them as an identifier ÂFoo ..."
In Macintosh Pascal dialects, Foo would be called a compiler variable (actually compile-time variable is the precisely correct term used in the Macintosh Pascal dialects' documentation) and they also go into different name space than the program's Pascal language declarations/definitions. (The supported syntax is also more elaborate supporting constant integer and boolean expressions [referred to as compile-time expressions] with assignments to compile-time variables supported.)
I think this difference in terminal may have lead to a few misinterpretations of various people's statements in the recent thread on CodeWarrior and THINK Pascal's propagating uses feature. (It doesn't help either when people [including myself] use imprecise terminology.)
So we're now at the point where not only the compiler, but also ourselves have to work with a mixture of various dialects in terminology. :-(
Since compatibility issues don't matter so much in natural language discussions (only habits do), I'd prefer, however, to try to keep some kind of common language for better mutual understanding.
In this case, I think "variable" is an unfortunate term since it has a well-defined meaning in Pascal which is not this one. "Compiler" [in "compiler variable"] is also questionable to me. If we consider the usual parts of the language processor (preprocessor, parser, compiler proper, assembler, linker, etc.), this would belong to the preprocessor stage (i.e., do some substitutions before the result is actually treated as Pascal code) -- BTW, that's independent of whether there actually is a separate preprocessor (as in GPC currently) or if that's done implicitly during the other steps (as I plan to do it). So "compiler" would be misleading. OTOH, if you consider everything together as the compiler, then the addition of "compiler" in the phrase really doesn't mean anything because everything is handled by the "compiler".
Now, "compile-time variable" sounds a bit better, but I'm still skeptical about the "variable" part because of danger of confusing it with real variables.
The point is, I think, that in GPC conditional compiler defines (macros set with $define)
They aren't really macros since they don't have the macro text editting effect. What GPC's documentation refers to as "conditionals" are distinctly different from macros.
They're actually the same as macros without parameters. E.g.:
{$define Foo 42} var a: array [1 .. Foo] of Integer;
means just
var a: array [1 .. 42] of Integer;
Or, perhaps making things clearer:
{$define Foo 1 + 2}
var a: array [1 .. 3 * Foo] of Integer;
means
var a: array [1 .. 3 * 1 + 2] of Integer;
Sic, no parentheses! So it's really just text substitution.
Conditionals are evaluated by substituting all macros they contain (just like anywhere else) and evaluating the expression. So:
{$define Foo 42} {$if Foo > 40}
becomes
{$if 42 > 40}
which yields true.
And, of course, there's `ifdef' etc., but this also works the same for macros with and without arguments.
Agreed, it isn't a big issue especially so in light of GPC's more extensive language support in the unit/module interface area. All things considered, it is probably best to avoid getting into compile-time variable propagation features since it is somewhat of a bucket of worms which no Macintosh Pascal compilers' documentation actually describes the behavior of.
I'm not surprised. When I thought about the ramifications of macros across units, I came to some pretty strange cases, too. So I'd also prefer to stay away from it.
Frank