Re: ADA context sensitive editor

[bl884@freenet.HSC.Colorado.EDU (Wes Groleau)]

In a previous article, griffin@acm.org (Michael D. Griffin) says:

>In article <3krv0g$7jb@theopolis.orl.mmc.com> Gerald Petrey,
>gpetrey@polo.dab.ge.com writes:
>>IMHO, Ada-Assured is the worst product to ever come out of Verdix. 
>
>IMHO, Ada-Assured is a good product for ensuring compilance with the AQ&S

I witnessed the adoption of Ada-ASSURED on a major product.  

1. It does not comes from Verdix.

2. Although a pretty good product, it does have a few significant flaws.
   One of these is that it cannot distinguish between functions and procedures
   for certain details (they said they would fix this, so if maybe the rest
   of this message is moot).

   We had a rule that default mode in could NOT be used in procedures but
   should be used in functions.  The rationale (hold the flames!) was
   a. making "in" explicit in functions suggests to the uninitiated that
      there is a possibility of another mode but "in" is the "right" mode
      for "this" application.
   b. Being explicit in procedures shows that you thought about it instead of
      doing something accidentally.

Ada-ASSURED was set to "fix" procedures if "in" was left out (actually 
contrary to the spirit of (b) but it's not my fault!)  This meant that "in"
was ADDED by the tool to functions.  If the spec was "frozen" before adoption
of Ada-ASSURED, the changed function does not conform and will not compile.