Re: [Q] Tools for Ada Quality and Style

[geert@fozzie.sun3.iaf.nl (Geert Bosch)]

Robert Dewar (dewar@cs.nyu.edu) wrote:
`` Such tools, to help entry, are found useful by many people. I find
   them annoying and completely useless, they just intefere with my
   typing speed. If I have to use one, I prefer Emacs ada-mode to DEC's
   LSE approach. ''

Since I'm working on an IDE for GNAT/OS2 I've evaluated some methods that were
mentioned to help entering Ada code.

My initial approach (although I don't like it myself) was to do the standard
syntax expansion that many editors provide: type 'if' and the 'then' and 'end if'
appear aligned correctly and the writer can fill in the blanks. 

Although it sounds easy, there are some nasty problems. The biggest is that your
code is correct even if it shouldn't be. Say I type 
   if P = null then
      Put_Line("Error in expression");
      _  (here I'm thinking about introducing a new exception type)
  end if;

Since the editor has supplied the 'end if' the code is correct and when I forget
to add a 'raise Expression_Error' or whatever, I won't notice it. This can cause
really nasty bugs and I've found in practise that leaving such constructions
'open' is a good safety measure.

Another problem is that I need to jump over the 'end if', or even need to remove
the empty line and I find it faster to type the end myself. Another problem is
that Ada makes guessing in most other statements rather hard. If I type 'for'
do I want to have a 'for' loop or a 'for ... use' construction? Does my 'accept'
want a 'do'? When I type 'package ... is', do I want to declare a package 
specification or generic package instantiation? Does my package body need a 
begin? Or did I want to type 'package body ... is separate;'? It's not really 
helpful to have an editor that makes wrong guesses on these things.

And then I do want *some* flexibility in doing the layout. 

To solve these problems I've only implemented indentation support. Having to indent
and unindent myself causes most slow-down. The only drawback I've found so far is
that's much harder to implement then the template approaches. Especially properly
aligning begins was really hard, especially if it must be possible to deal with
unfinished code. 

Here's some problem code that needs some parsing:

package body A is
   procedure B(D : in T; E : out T) is
      procedure C;
   begin
      ...
      declare
	 F : T;
      begin
	 ...
      end;
      begin
	 ... 
      end;
   end;

   procedure  D;

   begin -- here I press enter; the editor must find out B already has a body,
	 -- this begin is *not* a begin in the body and so, this begin must be
	 -- the begin of the package body.

Rober Dewar wrote:
`` For me I prefer a completely non-intrusive editor. Other people like
   an editor which complains to them about errors as they are entered.
   To each their own! ''

I'm really curious if you are going to find this an improvement or not.
For me it is in any case, and I'm happy with it. As far as I know, the
indentation rules used fit perfectly with the GNAT style.

Regards,
   Geert

-- 
E-Mail: geert@sun3.iaf.nl     *** As far as we know, there have not been ***
 Phone: +31-53-4303054        ** any undetected failures in our software. **