Re: Ada95=>Ada0Y Process? [was: circular unit dependency]

["John G. Volan" <johnvolan@sprintmail.com>]

Robert Dewar wrote:
> 
> John Volan asks
> 
> <<> My question for comp.lang.ada as a whole is this:  What mechanism, if
> > any, is currently established for evolving the Ada language standard?
> [snip]
>
> The current Ada standard is maintained by ISO WG9, with the technical work
> being done by its Ada Rapporteur Group. The ARG is concerned with clarifying
> the current standard and fixing any minor problems found, it is not concerned
> with evolving the standard. No formal group that I know of is concerned with
> the latter, and indeed I think any formalized discussions of changes to
> Ada 95 would be premature and non-constructive.

Yes, that is what I thought. Thank you.

(Just out of curiosity, is there a URL for ISO (and WG9 (and the ARG))?)

> Probably one of the most useful things at this stage would be for people to
> prototype possible new language suggestions using GNAT.

I have started looking at the GNAT 3.09 sources with that very
possibility in mind. With regard to the Ada0Y proposals I enumerated in
my FAQ:

- Scanner: The scanner most likely would not need to be modified, since
these proposals don't require any new reserved words or any different
treatment of lexical elements. (The most I could see there would be
possible new error handling situations with feedback from the parser.)

- Parser: The parser would need to be modified to recognize the new
syntax and generate new kinds of nodes and/or entities, e.g., the
forward incomplete types.  This does not look to be a huge amount of
work.

- Semantic Analyzer: The biggest part of the job would be in the
semantic analyzer, to deal with new situations involving forward
incomplete types spanning compilation units.  For instance, an ordinary
"with" clause would need new handling to deal with the possibility that
it provides the completion of a forward incomplete type. There would
have to be checks to determine that a forward incomplete type was
actually completed at the necessary places. And so forth.

A "divide-and-conquer" strategy is applicable here: "With type" clauses
(and the forward incomplete types they introduce) could be implemented
first and experimented with, and later one could experiment with
liberalizing incomplete types for use as "in," "out," and "in out"
parameters. (This is one reason why I broke up Tucker's original
proposal into two sections in my FAQ.)

- Expander/Gigi/Backend: I'm not sure I know enough there to estimate
what would need to be done, but I'm hoping changes to those parts can be
avoided.

Any advice you could give to someone contemplating such an adventure
would be greatly appreciated.

In particular, what would be the best way to structure such enhancements
so they would be maintainable given the on-going maintenance of GNAT?
 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using" & 
                 "them would be totally erroneous ... or is that"     &
                 "just nondeterministic behavior now? :-) ");
------------------------------------------------------------------------