Adriaan van Os wrote:
Well, as much as I welcome Frank's suggestions for the preprocessor, there really are compatibilty-concerns. CodeWarrior Pascal has integrated preprocessor support, similar to what Frank suggests. I have included relevant parts of the CodeWarrior Pascal Compilers Reference in the text below.
Well, the descriptions don't always seem to be very accurate. Besides some smaller mistakes, it lists some "Turbo Pascal compatible directives" (e.g., elif, error, if, macro, pragma) that at least BP 7.0 doesn't know (so I'd be surprised if previous TP/BP versions had them). Or this:
$IFNOTC {$IFNOTC DEFINED name}
Compiles subsequent source code until the next $ELSEC or $ENDC directive, only if the boolean value of comp-expr is true.
comp-expr is not even mentioned in the heading, and I suppose it must read "false" instead of "true".
So I'm discarding the exact wording in favour of reading the text in a "reasonable" (IMHO) way ... ;-)
You can form compile-time expressions out of compile-time variables or constants of type INTEGER or BOOLEAN.
That would be a reason for integrating the preprocessor into the compiler since a stand-alone preprocessor would have no knowledge of constants.
However, I actually don't like this very much. I prefer the preprocessor output to be a function of the source code and the initial settings.
Otherwise, it would also depend on imported modules (used units) which may define constants ...
$DEFINEC Items defined in the INTERFACE part of a unit are accessible by the units or the program that use the unit.
For the same reason I don't like this, either. (And it would also require an integrated preprocessor.)
BTW, these things would also make the task of external programs such as `gp' much more difficult (since, e.g., `uses'/`import' could be within a conditional).
Apart from this, most seems to boil down to aliases of existing directives:
definec define elifc elif endc endif errorc error ifc if macro define undefc undef
Of course, this would be easy to do, but I don't see the big point in it. Especially since "CodeWarrior Pascal-compatible directive[s] ... may not be used in the same source code file as Turbo-compatible directives". It seems they're just creating artifical incompatibilities by just calling the same directives differently. :-(
{$IF OPTION(option-name) } {$IF OPTION option-name }
Another syntax for `ifopt'.
{$IFC DEFINED name} You may also write this directive in the form {$IFC DEFINED name}. This will act like {$IFC false} if name has not yet been de- clared with a $SETC directive; otherwise, it will act like {$IFC true}.
GPC currently has `defined (name)'. The parentheses seem more "Pascalish" to me (cf. `sizeof foo' in C vs. `SizeOf (foo)' in BP which I actually consider more Pascalish here). Though it shouldn't be a big problem to implement it without the parentheses, too ...
$IFNOTC {$IFNOTC DEFINED name}
Compiles subsequent source code until the next $ELSEC or $ENDC directive, only if the boolean value of comp-expr is true.
Same as `if not (...)'. (Since `not' is apparently allowed already in conditionals, this seems rather redundant ...)
$PRAGMAC {$PRAGMA pragma state}
Sets the state of a pragma. See Pragmas on page 60 for more infor- mation on using pragmas to control how source code is translated into object code.
I don't know what pragmas are, I guess they're the same as (some) compiler directives in GPC (and possibly BP), and could possibly be mappend to them ...
$SETC {$SETC id := comp-expr}
Declares a compile-time variable named id and assigns it the value comp-expr.
So there's another mechanism besides defines (and usual Pascal constants etc., of course)? I'm not convinced this is very useful. (Even C, which makes heavy use of the preprocessor and uses defines for constants, seems to be quite happy with only one preprocessor "name space".) So if anything, I think it might be reasonable to make this equivalent to `{$define id comp-expr}'.
All in all, these features don't seem to add new capabilities (with the exception above, working across units, that I don't like), just more syntax alternatives. I think about it mostly the same as about some Delphi features ... :-(
I.e., we might choose to implement them for compatibility's sake. Then again, how far is GPC compatible to CW in other respects? Is it reasonable to claim (or strive for) compatibility at all?
Frank