From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!inmet!stt
From: stt@inmet.inmet.com
Newsgroups: comp.lang.ada
Subject: Re: preprocessing & optimization
Message-ID: <20600028@inmet>
Date: 21 Dec 89 20:58:00 GMT
References: <7491@hubcap.clemson.edu>
Nf-ID: #R:hubcap.clemson.edu:7491:inmet:20600028:000:3995
Nf-From: inmet.inmet.com!stt    Dec 21 15:58:00 1989
List-Id: <comp.lang.ada>


Regarding preprocessors, optimization, and standardization:

I was talking about preprocessors in the "C Preprocessor" vein.
E.g., defines, ifdefs, etc.

I am sorry if I gave the impression I was talking about
a preprocessor like C++ 2.0.  Such a "preprocessor" is
really a full compiler which happens to emit C rather than
object code.  For the C++ kind of "preprocessor," you are absolutely
right that optimization of the output can be more difficult.

I also presume that Dave Emery's proposal for Ada was oriented toward
the conditional compilation type of preprocessor.

Frankly, I had personally written off the concept of a standard
preprocessor for Ada.  However, seeing the interest in Dave's
proposal, it seems worth considering again.  
As a compiler implementor, I hated the old "pragma Include" because
it made automatic recompilation a different kind of problem.
As it is now, it is possible to recompile from parse trees.
With "pragma Include," that was effectively impossible.

However, I *can* imagine a careful definition of conditional
compilation mechanisms which would preserve the ability to
recompile from parse trees.  This would *not* be a preprocessor
approach, however.  Instead, it would mean creating new
syntax.  Here is a quick proposal:

   Allow if constructs and case constructs within a sequence of
   declarations, so long as all conditional and case
   expressions are static, and each if/case "arm" contains
   only declarations (rather than statements).

Note that variant records already use the case construct at the
end of a list of declarations.  This proposal would simply generalize
this a bit (?), and allow the case expression to be an arbitrary
static expression as well as the currently-legal discriminant.
Furthermore, identifiers *could* be reused in mutually exclusive
if/case arms, since this would not interfere with
compile-time type checking.

One could even imagine allowing if/case constructs in context clauses,
to do conditional "with"ing.

The nice thing about this kind of approach is that it builds on the
existing concepts of the language (namely static expressions,
if/case constructs, and variant records), rather than introducing
a new/foreign syntax like "#ifdef".  

It is interesting to compare the situation
in Ada with that in C++.  Now that C++ has the concepts
of inlines and "consts" the need for preprocessors is reduced for C++,
though apparently not eliminated (for the same reasons that Dave
is providing for Ada).
It seems like it might be a better solution in the C++ arena
to also start allowing conditional constructs among declarations,
and strip them out as part of generating C (presuming that the
C++ "compiler" already has to be able to evaluate static expressions).

Here is an example demonstrating this proposal (though I admit
this example could probably be done better using other methods):

    with Parameters;
    package Fum is
        case Parameters.Target is
	    when Parameters.VAX =>
                type Target_Double is digits 11;
            when Parameters.S370 =>
		type Target_Double is digits 14;
	    when others =>
		type Target_Double is digits 15;
	end case;
        . . .
    end Fum;

Probably an important additional requirement would be that
the arms of an if/case construct which are not chosen
should not be required to be semantically correct (though
they would still require syntactic correctness).  This
should apply whether the if/case construct is acting as a declaration
or a statement.  This would allow reference in such unselected arms
to declarations which were similarly unselected.  This also
has the net effect of mandating conditional compilation, rather
than leaving it as an optional "optimization."

And while we're at it..., AI-00128 which disallows use of short-circuit
control forms in static expressions should probably be revisited.
-----------------------
S. Tucker Taft   uunet!inmet!stt; taft@ajpo.sei.cmu.edu
Intermetrics, Inc.
Cambridge, MA  02138