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!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!MBUNIX.MITRE.ORG!emery
From: emery@MBUNIX.MITRE.ORG (Emery)
Newsgroups: comp.lang.ada
Subject: limitations on optimizers for conditional compilation
Message-ID: <8912110202.AA11909@mbunix.mitre.org>
Date: 11 Dec 89 02:02:44 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

Armin points out that it is perfectly legal to do conditional
compilation of statements based on some (constant) boolean value.
This is something I'd expect a good compiler to do, and a technique
that I have used (sending prayers to the God of Compilers that my
compiler was "good").   

Where this approach fails, though, is in non-statements such as type
declarations.  It would be nice to have support for this:
	type foo_bar is 
	  record
	    x : integer;
#ifdef VAX
	    y : float_64;
#elsif IBM_PC_WITH_8087
	    y : IEEE_float;
#endif
	end record;

I suspect that the very clever person could use variant records for
this example, but I also suspect that it wouldn't take much to come up
with type definitions where a variant record approach wouldn't work.

Using these ("constant type") variant records would probably make the
program harder to read, because it wouldn't be clear to the maintainer
if this was a variant record object (or subtype) based on some 'real
variant) or based on some conditional compilation feature.  Objects
are often widely separated from their declaration, compared to
(optimizable) conditional compilation statements.
				dave 
				emery@aries.mitre.org