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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ec2b9b815bd3b0bd
X-Google-Attributes: gid103376,public
From: mfb@mbunix.mitre.org (Michael F Brenner)
Subject: Re: Conditional Code in Ada 95?
Date: 1998/08/26
Message-ID: <6s1kba$hck@top.mitre.org>#1/1
X-Deja-AN: 384999597
References: <35DDFB42.1311@boeing.com> <2$$CdIjQwTPX@nedcu4>
 <6rrtuf$cqg@top.mitre.org> <6rtike$b3$1@nnrp1.dejanews.com>
Organization: none
Newsgroups: comp.lang.ada
Date: 1998-08-26T00:00:00+00:00
List-Id: <comp.lang.ada>


Mike > Yes, constants are good for executable statements. However, there is
     > no way WITHIN the Ada language to select which of the hardware
     > specific bodies to use with a multi-platform package.
     > This is to be considered a requirement for Ada 200X.

Responder > I can't see what has changed that should suggest reconsidering
          > this decision. Steelman specified no conditional compilation in
          > Ada, Ada 83 carefully considered that specification and agreed
          > with it, and Ada 95 also agreed. I see no reason to revisit this
          > unless there is new information, there has always been general
          > agreement that conditional compilation does not belong in the
          > language proper. 

You are right, as far as a C-preprocessor making the code harder to read.
However, the requirement would not be for a preprocessor, but for a
means WITHIN the language of selecting from among multiple package
bodies which share the same face (package specification modulo
the WITH list and the private part).

Jean Pierre > with Hardware_Specific_1;
            > package Hardware_Specific renames Hardware_Specific_1;

This work beautifully in many cases in Ada-95. For those projects
that are stuck in Ada-83 a little while longer until the remaining
bugs in various Ada-95 compilers or annexes are being worked out,
this is not possible, because Ada-83 forbids it. Because of problems
with supporting DOS, packed arrays, and other reasons, etc., the 
majority of code in the Ada language still must adhere to Ada-83.
 
Responder > Michael, what new information is available
          > that would suggest revisiting it (the fact that 
          > Michael Brenner wants it does not count as new information :-)

I am curious why you think that the requirements process should
not count requirements originating from me, a large user and
maintainer of Ada software? It should be a requirement of Ada 200X
that all of us can give inputs to the requirements process and
participate in the decision making process as well. I will start
by graning you amity -- I will consider any requirements that
originate with you, and will accept them unless I have a good reason
not to. I will count all of your requirements and suggestions as
a valuable contribution to the community.

However, it is approrpriate to repeat here the admonition that the
primary changes in  Ada 200X should be efficiency improvements and
language definition-bug-fixes, as opposed to major changes. The
only substantial addition to Ada 200X should be a full set of 
interfaces to the open (non-proprietary) standards like Java/SQL/
ODBC/JDBC/DOS/Posix/ and to common I/O devices like mouses, SCSI disks,
CDs, MIDI instruments, superVGA pixels, serial ports, interrupts, and
multiple keypress immediate keyboards.

Some of the changes in Ada 200X are:
  - get rid of any UNNECESSARY checking in various chapters
  - permit passing nongeneric packages to generic packages
  - keep things static that were static before passing them to generics
  - a way to select which body to compile for platform independent packages,
  - use a stream_io.stream intead of a text_io.stream for text_io
  

Mike