From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,15890893c0618a8a X-Google-Attributes: gid103376,public From: geert@fozzie.sun3.iaf.nl (Geert Bosch) Subject: Re: [Q] Tools for Ada Quality and Style Date: 1996/05/05 Message-ID: <4miagm$1mb@fozzie.sun3.iaf.nl>#1/1 X-Deja-AN: 153163792 references: <9604172134.AA27114@eight-ball> <767968529wnr@diphi.demon.co.uk> <4ltjat$dao@parlor.hiwaay.net> <4m3ouj$b0p@inferno.mpx.com.au> organization: La Calandre Infortunee newsgroups: comp.lang.ada Date: 1996-05-05T00:00:00+00:00 List-Id: 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. **