9X and the NEED for preprocessing

9X and the NEED for preprocessing

[Bob Munck]

Dave Emery is essentially raising an interesting question sequence:

IF the use of preprocessors for Ada code is at all wide-spread THEN

   ASSUME uncontrolled use of random preprocessors is not in
          agreement with the general principles of Ada use;

   IF the things being done with preprocessors can 
      be done easily and understandably in legal Ada THEN

      Write a note/article/book describing the problems being solved
      with preprocessors and the way they should be solved with Ada;

   ELSE

      IF some set of Ada-9X revision suggestions 
         would make it possible to do so in Ada-9X THEN

         List them and describe how they solve the problem;

      ELSE

         ASSUME the Ada-9X revision submission period is over;
         Suggest that we have a problem

      END IF
   END IF
END IF

(My apologies for the cutesy if-then-else format.)  I think it's likely
that the result of "running the program" is to suggest that we have a 
problem, but I'm not at all familiar with the submitted suggestions.

                                  -- Bob Munck, MITRE McLean

Re: 9X and the NEED for preprocessing

[stt]

With regard to Ada preprocessors, and Ada9X:

First of all, preprocessors create no optimization problem,
since they operate at the lexical, or possibly syntactic, level,
long before the optimizer takes a look at the program.

However, I am not a great fan of Ada preprocessors.
We have implemented a compiler system and development tools
for 6 targets and 7 hosts without using a preprocessor.
Our general strategy is to define one or more target/host-independent
package specs with target/host-dependent bodies.
We minimize the size of such packages, and simply reimplement
them for each distinct target/host.

Sometimes, the package spec is target/host-dependent as well,
but only in its definitions, not in the names defined (e.g.,
one host might define the type "Link_Name" as being an 8 character string,
another might define it as being a 30 character string).

The net effect of this approach is that a particular configuration
is determined by a set of source files, not a set of preprocessor
switches.  Also, for cases where we do restrict differences to bodies,
we can select a different configuration at link time by choosing
a distinct "implementation catalog variant" (in Intermetrics AIE-speak),
requiring no recompilation.

Anyway, so much for truth and beauty.  If there is a compelling
argument for a standardized preprocessor, I am sure that the Ada9X
process will be willing to consider it, even though the "official"
public revision request period is over.  The Ada9X process is
going to include a number of public reviews, and the various
project teams working on Ada9X will continue to keep their
ears open for brilliant and/or urgent proposals.

S. Tucker Taft  (Ada9X DR -- aka "distinguished" reviewer)
Intermetrics, Inc.
Cambridge, MA  02138

Re: 9X and the NEED for preprocessing

[arny.b.engelson]

In article <20600027@inmet> stt@inmet.inmet.com writes:
>
>With regard to Ada preprocessors, and Ada9X:
>
>However, I am not a great fan of Ada preprocessors.
>We have implemented a compiler system and development tools
>for 6 targets and 7 hosts without using a preprocessor.

I doubt there is a situation that REQUIRES the use of a preprocessor, but
that doesn't mean we shouldn't have one.  We don't really NEED a "for loop"
in Ada, nor recursion, nor many other features that one programmer chooses
to use while another does not.  That doesn't mean we shouldn't have them.

>Our general strategy is to define one or more target/host-independent
>package specs with target/host-dependent bodies.
>We minimize the size of such packages, and simply reimplement
>them for each distinct target/host.
>Sometimes, the package spec is target/host-dependent as well,
>but only in its definitions, not in the names defined (e.g.,
>one host might define the type "Link_Name" as being an 8 character string,
>another might define it as being a 30 character string).

This is my preferred strategy as well, and I believe it is the "better"
method (since it stays within the language), but not all programmers agree.

Differences in package specs generally require a lot more compilation
to go from one target to another.  I think it also tends to be harder to
split the constant code from the code that varies by target when you are
dealing with package specs.  There tend to be a lot of dependencies.

>The net effect of this approach is that a particular configuration
>is determined by a set of source files, not a set of preprocessor
>switches.  Also, for cases where we do restrict differences to bodies,
>we can select a different configuration at link time by choosing
>a distinct "implementation catalog variant" (in Intermetrics AIE-speak),
>requiring no recompilation.

This doesn't work when your targets use compilers from different companies.
Sometimes you have no choice in picking your compiler(s) or your targets.
Also, what do you do when you have different variations of a package body,
and must change a piece of code that is common to all of them (but was too
difficult to split out)? You end up making the same changes in each version
of the package body.

>Anyway, so much for truth and beauty.  If there is a compelling
>argument for a standardized preprocessor, I am sure that the Ada9X
>process will be willing to consider it, even though the "official"
>public revision request period is over.  The Ada9X process is
>going to include a number of public reviews, and the various
>project teams working on Ada9X will continue to keep their
>ears open for brilliant and/or urgent proposals.
>
>S. Tucker Taft  (Ada9X DR -- aka "distinguished" reviewer)
>Intermetrics, Inc.
>Cambridge, MA  02138

As to what would constitute a compelling argument, I don't know.  But, I
can say that there are times a preprocessor is a handy thing.  We have a
case with multiple targets and multiple compilers (sorry, I can't be very
specific), resulting in (some parts of the code) up to 10 different versions
of a package.  This includes some targets with functionality left out, other
functionality added, different record (bit) layout, etc.  Some vary in the
definitions.  We also have different customers with slightly different
requirements and using different subsets of target processors.

Imagine maintaining 10 different versions of a file and ensuring that they
are all functionally equivalent (in their common areas).  Some of this is
reduced by proper separating of the common code from the code that changes,
but in some cases this is not possible.  A preprocessor can ease
maintainence and testing, and provides a convenient way to add/remove
performance monitoring and debugging code.  It's not for me, but it may be
for others, and therefore we will all benefit from it being standardized.

As for the Ada9X process, I don't think it necessary that a standardized
preprocessor effort be tied to Ada9X.  A preprocessor is not part of the
language, it is a support tool.  It can easily be a separate effort
(such as CAIS, Ada/POSIX, Ada/SQL, etc.).  Besides, I think it is a more
difficult task than it may first seem.  What I think can end up being a
problem is contractual legalities (the code is not pure Ada).  Of course,
we could MAKE a preprocessor part of the language, forcing all compilers
to support it, adding ACVC tests for it, etc.

  -- Arny Engelson   att!wayback!arny

Re: 9X and the NEED for preprocessing

[Michael Hunter]

>I doubt there is a situation that REQUIRES the use of a preprocessor, but
>that doesn't mean we shouldn't have one.  We don't really NEED a "for loop"
>in Ada, nor recursion, nor many other features that one programmer chooses
>to use while another does not.  That doesn't mean we shouldn't have them.
We HAVE to have (some form of) recursion.  There are some things that just
can't be unrolled.

                                        Michael

Mike Hunter - Box's and CPU's from HELL: iapx80[012]86, PR1ME 50 Series, 1750a
UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!bagpiper
INET: bagpiper@pnet02.gryphon.com