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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: pdmillik@mpx.com.au (Peter Milliken) Subject: Re: [Q] Tools for Ada Quality and Style Date: 1996/05/07 Message-ID: <4mon5m$9dt@inferno.mpx.com.au> X-Deja-AN: 153632737 references: <9604172134.AA27114@eight-ball> <767968529wnr@diphi.demon.co.uk> <4ltjat$dao@parlor.hiwaay.net> <4m3ouj$b0p@inferno.mpx.com.au> <4miagm$1mb@fozzie.sun3.iaf.nl> organization: Microplex Pty Ltd newsgroups: comp.lang.ada Date: 1996-05-07T00:00:00+00:00 List-Id: Geert Bosch (geert@fozzie.sun3.iaf.nl) wrote: : 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. '' I can understand and sympathise with Robert's remark here, but has anyone really noticed how few programmers can actually "type"? By that I mean full 80 wpm touch typing. Most of us are reasonably fast several finger pickers who at some time in our career try to learn touch typing and give up when our favourite editor forces removal of the fingers from the "home" keys too often. : : 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. : <> : : Regards, : Geert I think all your problems could be cured by the LSE approach to program entering for instance: [source file header comment] [context_clause]... package body {package_simple_name} is [declarative_part] begin if {condition} then {statement}... [elsif_part]... [else_part] end if; [statement]... [exception_part] end [package_simple_name]; Here is a short snippet generated by a LSE-like minor mode I am currently implementing for Emacs. Simple commands linked to functions keys moves the cursor between 'placeholders' (keywords enclosed by {} or []'s). Typing within the {package_simple_name} will automatically be duplicated in the [package_simple_name] space after the 'end', no deletions are required, just function key to the placeholder and start typing. 'Prompters' are provided by placeholders (optional) like the [exception_part] so you should not forget to provide for catching any raised exceptions. Placeholders that can lead to several possible constructs provide menu choices on 'expansion' (can be of aid to learners of the language) so there are no real problems selecting which one you want. I guess that this system will never help with forgetting to raise the exception in the if statement, however, there will always be a placeholder that you have to consciously delete (the [statement]... is a automatic repeater [denoted by the 3 '.'s]) I generated the above skeleton is in about 8 keystrokes, I think this will boost my productivity to a similiar level as that achieved by a good typist such as Robert, with one important difference, I won't get any syntax errors when I compile my (completed) package body, the typical (please note Robert, I am not having a go at you) typist will have syntax errors and will have to typically compile a number of times prior to getting all such errors out of the way before tackling the (typically) harder issues of what the incorrect types the programmer may have entered etc. I am implementing LSE as a minor mode for Emacs and am generating templates for Ada95. Because it is a minor mode, a user will be able to use it with any programming language, not just Ada, all they have to do is enter the template definitions (that's all :-) whew... Ada95 has taken a lot of work!) I assume that Apex is limited to whatever languages Rational support (?) and whilst I hope one day to see this editor in action I fear that I will be limited to using the freebies like Emacs and anything I can put together myself for some time. -- --------------------------------------------- _--_|\ | Peter Milliken (pdmillik@mpx.com.au) / \ | CAE Electronics (Australia) Pty. Ltd. \_.--._/ | 120 Silverwater Rd, Silverwater, N.S.W., 2128. v | P.S My opinions are my own, I don't know what my companies are, I don't think they have any... :-)