Somewhere back in time (a few years ago, in fact), it became standard in my Pascal-P series work to use SED to generate different versions of the source code. It started with the need to change the memory store[] size to a smaller size so it would self compile (to make it short, if the code array pint.pas stores all its code and variables in is the same size as what it is running on, it overflows - you cannot put the same size box in itself).
As part of the self compile, it also needed a SED fix to remove the declaration and reset/rewrite of the prr and prd header files, because the host compiler does not know about these predefined header files, but the compiled Pascal-P does know about them, and (by the rules of ISO 7185) those files are considered handled by the compiler itself.
Finally, a different set of defintions was needed for each of 32 and 64 bit modes. Perhaps the inflection point was that cmach.c, the interpreter translated to C, used standard preprocessor statements (#xxx) to accomplish those changes. I decided that the current "do it yourself" macro system was overcomplex, and would be simpler if we just used the C preprocessor itself. Well, with a bit of work, I discovered that using CPP, the C PreProcessor (and no, not the C++ compiler) with other languages is actually quite easy.
Thus in the next patch I embrace the C preprocessor, and have converted all of the code to use that system exclusively. This has the following advantages:
Uses one method, #ifdefs and the like, to accomplish all source code configuration.
Is a well known and widely available standard.
Can do things like complex expressions to decide whether or not to include code configurations.
So why the title "I give up"? Well, if you knew me you would know that I really, really (really) hate macros. As a compiler guy since like, ever, I believe in the power of language processing and not macros. Macros just cut and paste text without any knowledge of what is being cut and pasted, then disgorge the result looking like code fed through a cusineart to the compiler. Figuring out other peoples macros, especially when they go wrong, is a real job. I once had to dumpster dive through a series of 10 level deep macros for a large body of code to find out what the problems were.
Macros are useful in assembly language, mostly because assemblers have no real intellgence about what is being assembled (beyond if the instructions are correct or not), and macros are a way of building a higher order of implementation on it. In fact, IP Pascal has an assembler with a quite extensive and flexible macro capability that, ahem, does not do searching (as most macro processors do) and is therefore fast.
The C language had a macro preprocessor because it lacked the ability to declare constants, and back in the old days when the language started (1970's), it also didn't have the ability to inline code. Neither of those is true anymore, but I will admit that trying to create manifest constants in C appears to show the folks who added that capability to ANSI C haven't used it themselves much, but that is another story.
Thus, although I know several people who have applied a macro processor to Pascal, I am not a fan. Pascal does not need, nor does it deserve, a macro processor. Thus I have avoided showing its use in the Pascal-P series ("see? This is wrong, don't do this even though I am doing it"). To be fair, P6 is not, in fact, using macros, but rather code block configuration using #ifdefs, not macros.
Now why would Pascal need a macro processor? Well, actually there are a lot of reasons:
You cannot form constant expressions to declare types and other objects.
The order of declarations is fixed (const, type, var, etc.).
There is no modularity.
However, Pascaline/P6 fixes these things, so hopefully we are back to not needing a preprocessor capability. On the other hand, P6 is written in ISO 7185, so there you go.
So P6 uses CPP, the C preprocessor now. It works well for #ifdefs and similar items, given the correct options. The CPP documentation itself warns against assuming it works with other languages (than C). Remember it is expecting to see C style comments and quoted strings and characters. If you decide to use it to create "real" macros, that is, things like #define callme(a, b) ... you are so on your own.
Last edit: Scott Franco 2018-09-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CPP is already proliferating in P6. It badly needed an include, and now I see several things that an include allows to be moved out of the mainline code and no longer duplicated per file.
The strict C preprocessor definitions used don't match either GPC nor FPC, which use a system based on compiler comments (like {$...}, which were by the way introduced in the original Pascal-P system). It does however match the system in IP Pascal, since the first days (1980).
My feelings about this are mixed, and not just because of the macro complaint above. It tends to reorder the code in a way foreign to ISO 7185. This is a good reason to limit it's use.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Somewhere back in time (a few years ago, in fact), it became standard in my Pascal-P series work to use SED to generate different versions of the source code. It started with the need to change the memory store[] size to a smaller size so it would self compile (to make it short, if the code array pint.pas stores all its code and variables in is the same size as what it is running on, it overflows - you cannot put the same size box in itself).
As part of the self compile, it also needed a SED fix to remove the declaration and reset/rewrite of the prr and prd header files, because the host compiler does not know about these predefined header files, but the compiled Pascal-P does know about them, and (by the rules of ISO 7185) those files are considered handled by the compiler itself.
Finally, a different set of defintions was needed for each of 32 and 64 bit modes. Perhaps the inflection point was that cmach.c, the interpreter translated to C, used standard preprocessor statements (#xxx) to accomplish those changes. I decided that the current "do it yourself" macro system was overcomplex, and would be simpler if we just used the C preprocessor itself. Well, with a bit of work, I discovered that using CPP, the C PreProcessor (and no, not the C++ compiler) with other languages is actually quite easy.
Thus in the next patch I embrace the C preprocessor, and have converted all of the code to use that system exclusively. This has the following advantages:
So why the title "I give up"? Well, if you knew me you would know that I really, really (really) hate macros. As a compiler guy since like, ever, I believe in the power of language processing and not macros. Macros just cut and paste text without any knowledge of what is being cut and pasted, then disgorge the result looking like code fed through a cusineart to the compiler. Figuring out other peoples macros, especially when they go wrong, is a real job. I once had to dumpster dive through a series of 10 level deep macros for a large body of code to find out what the problems were.
Macros are useful in assembly language, mostly because assemblers have no real intellgence about what is being assembled (beyond if the instructions are correct or not), and macros are a way of building a higher order of implementation on it. In fact, IP Pascal has an assembler with a quite extensive and flexible macro capability that, ahem, does not do searching (as most macro processors do) and is therefore fast.
The C language had a macro preprocessor because it lacked the ability to declare constants, and back in the old days when the language started (1970's), it also didn't have the ability to inline code. Neither of those is true anymore, but I will admit that trying to create manifest constants in C appears to show the folks who added that capability to ANSI C haven't used it themselves much, but that is another story.
Thus, although I know several people who have applied a macro processor to Pascal, I am not a fan. Pascal does not need, nor does it deserve, a macro processor. Thus I have avoided showing its use in the Pascal-P series ("see? This is wrong, don't do this even though I am doing it"). To be fair, P6 is not, in fact, using macros, but rather code block configuration using #ifdefs, not macros.
Now why would Pascal need a macro processor? Well, actually there are a lot of reasons:
However, Pascaline/P6 fixes these things, so hopefully we are back to not needing a preprocessor capability. On the other hand, P6 is written in ISO 7185, so there you go.
So P6 uses CPP, the C preprocessor now. It works well for #ifdefs and similar items, given the correct options. The CPP documentation itself warns against assuming it works with other languages (than C). Remember it is expecting to see C style comments and quoted strings and characters. If you decide to use it to create "real" macros, that is, things like #define callme(a, b) ... you are so on your own.
Last edit: Scott Franco 2018-09-11
A few further notes:
My feelings about this are mixed, and not just because of the macro complaint above. It tends to reorder the code in a way foreign to ISO 7185. This is a good reason to limit it's use.