Re: GNAT Opinions

[mfb@mbunix.mitre.org (Michael F Brenner)]

    > gnat compiling policy is restrictive, and despite the *nice* gnatchop,
    > it is difficult to maintain both versions with unique sources. 

This hits the nail on the head, that gnat requires a library system
as a wrapper to maintain the read-only version being compiled,
separately from the read-write version being developed. This is
very similar to DEC Ada's and Alsys Ada's option of permitting
a copy of the source code being kept in the library for debugging
messages. Only in gnat, it is REQUIRED to put a copy of the code
into the library. 

The problem is that all other Ada compilers prior to gnat have
provided a library wrapper around their compiler, so the programmer
did not have to develop tools to do this chore. 

The good point of this is that it saved gnat the effort of building
the library wrapper, and therefore speeded up gnat development.

The bad point is that we each have developed our own library
wrappers for keeping track of the two version (or NOT keeping
track of them as the case may be). 

However, I would like to suggest that this is not a compiler
issue at all, but a developement environment issue, that is,
an APSE issue, a library issue.

APSE issues should be tracked, but they have little to do with
the compiler itself. 

In tracking compilers you are interested in a triangle of concerns:
(A) bugs detected at compile time (type 1 and type 2 errors)
(B) performance of the generated code (memory and time and threads)
(C) bugs in the compiler and how fast they are fixed

The APSE (library, configuration manager, cross referencer, data flow
diagrammer, calling tree displayer, debugger, automatic code 
generators like CASE tools, cohesion metrics, coupling metrics,
volume metrics like sloc or complexity, database management systems, 
APIs to connect to java byte codes or x windows or whatever,
libraries of objects like containers or networks, and so forth)
should be tracked separately from the compiler (IMO).

Mike Brenner