Adriaan van Os wrote:
Frank Heckenbach wrote:
Gale Paeper wrote:
In essense, it is a combination of C header mechanisms with Pascal's unit mechanics. In effect, it is a poorman's implementation of Extended Pascal's import and export parts without all the fine grained control features like renaming and selective imports and exports. To make it work, though, the compiler has to be able to propagate compiler variable defines through the uses clause chain to avoid a boatload of redunant compiles and multiple redeclarations. I have the impression that GPC doesn't support that sort of compiler variable propagation so Apple's unit and include file methods and organization isn't going to work.
I don't understand what you mean, so I can't answer your question. Variable declarations in units surely work -- but that's nothing special. Uses propagation (whether routines or variables) doesn't work in GPC as you know. So I suppose you mean something different.
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:
"BPs conditional definitions ({$define Foo}) go into another name space than the programs 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.)
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.
don't extend unit boundaries, where in traditional Macintosh Pascal compilers they do extend unit boundaries. I understand why this is so in GPC and for the Apple Interfaces it is not a big issue. We have found ways around it to make both "include" and "uses" mode work for the Apple Pascal Interfaces that we are porting to GPC.
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. (It wasn't until the late '80s that MPW Pascal even allowed include file directives in a unit's interface part and the documentation was never revised to indicate the change. THINK Pascal has never supported include file directives and compile-time variables don't propagate to used units [I know they don't in the non-propagating uses case but I've never checked the progating uses case to see what happens.] CodeWarrior Pascal can charitably be described as an amazingly unique implementation with a treasure trove of undocumented surprises and gotcha's in the compile-time variable, unit interfacing, and include file areas.)
Although it would be pretty difficult to accomplish for the Macintosh interfaces especially so without support tools, Extended Pascal's interface-specification-part (i.e., export) seems to be the best way to construct a comprehensive, everything-that's-needed interface for a module/unit since it avoids all the problematic issues inherent in unit/include file combinations.
Gale Paeper gpaeper@empirenet.com