Ada Programming Environment [was ifdef replacement for GNAT]

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

Aha, but Larry, you miss Michael's point: the Ada standard does not
prescribe the way in which different 'versions' of code (e.g. package
bodies) are selected for compilation into a version of a program. So
supplier A provides one method, supplier B provides another, and so on. This
is the sort of anarchy which Ada was intended to prevent.

Of course, this issue goes beyond just conditional compilation, to the
(fairly well discussed) issue of the Ada programming/development environment
(APSE or whatever).

(Along with others) I would suggest that one of the broad issues Ada 200X
should address is the issue of the programming environment. Whilst,
doubtless, much would be impossible to standardise, I feel that much could
be; and it would surely be a great boon to Ada programmers everywhere to
have even a partially standardised environment to work in.

I realise there are things like COE out there, but they all have problems
(as regards wider implementation). And, with respect, they are not written
by the talented people who created Ada (83 & 95), nor are they subject to
the same rigorous review process.

Michael's discursion on the subject of I/O (a classic Brennerism (MFB is
_unique_)) is (to me) fascinating. Mentioning no names, there are some
real-time operating systems which use a central 'software bus' in a way very
similar to what Michael describes. And the idea works provably well, too. A
lesson there, I feel sure.

For those of you who are not studied in Turing (shame on you!:-), it is
perhaps interesting to note that every program is just a means of
translating an input stream into an output stream. Some programs can even do
it backwards ;->

--
Nick Roberts, Croydon, UK
Nick.Roberts@dial.pipex.com

Larry Kilgallen wrote in message <1998Apr13.124600.1@eisner>...
|In article <6gt6ij$q6o@top.mitre.org>, mfb@mbunix.mitre.org (Michael F
Brenner) writes:
|
|> These are good steps. However, there still needs to be a need for
|> conditional compilation for three reasons.
|
|Regardless of the presence of reasons for supporting inline conditional
|compilation, I believe the current state of affairs is the correct one,
|due to the overwhelming strong reason for _not_ supporting it -- namely
|that it will get abused.  Take a look at any multi-platform C program.