Gnat pretty printing

Gnat pretty printing

[Matt Tyler]

Hi,

Sorry if this is  slightly off topic but I couldn't find a newsgroup on
specific compilers.

Does anyone know if it is possible for my gnat ada compiler running under
win95 pretty print? I.e. change font or use bold type for reserved words
etc??



--
Regards

Matthew Tyler

tylerm@logica.com

The opinions expressed here are my own and not necessarily those of Logica.

Re: Gnat pretty printing

[Steve O'Neill]

Matt Tyler wrote:

> Does anyone know if it is possible for my gnat ada compiler running under
> win95 pretty print? I.e. change font or use bold type for reserved words
> etc??

Well GNAT the compiler doesn't do this (nor would I expect it to).

Another tool that does do this is GRASP developed at Auburn University.  It
does some interesting things in addition to the 'normal' pretty printing.  Yes,
there is a Win95/NT version.  You can download it from
http://www.eng.auburn.edu/department/cse/research/grasp/

Good luck,

Steve O'Neill

Re: Gnat pretty printing

[dennison]

In article <74lt16$9r0@romeo.logica.co.uk>,
  "Matt Tyler" <tylerm@logica.com> wrote:
> Does anyone know if it is possible for my gnat ada compiler running under
> win95 pretty print? I.e. change font or use bold type for reserved words
> etc??

Emacs does that for you. If you want the output printed though, you need
access to a postscript color printer. However, I've printed colorized Ada
buffers to a file and converted that file to PDF for online read-only
viewing, with very nice results. But of course the reader needs Adobe
Acrobat.

Anyone have a Postscript to HTML converter?

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Gnat pretty printing

[David C. Hoos]

Matt Tyler wrote in message <74lt16$9r0@romeo.logica.co.uk>...
>Hi,
>
>Sorry if this is  slightly off topic but I couldn't find a newsgroup on
>specific compilers.
>
Pretty printing is not a compiler-specific subject, but there is a gnat mail
list to which you can subscribe at the www.gnat.com Web page.

>Does anyone know if it is possible for my gnat ada compiler running under
>win95 pretty print? I.e. change font or use bold type for reserved words
>etc??
>
The best thing I've found for this is a2ps (ASCII to Post Script) at
http://www-inf.enst.fr/~demaille/a2ps/


Of course, this means you'll need Post Script printing capability, and if
you don't already have it, I recommend Ghostscript  for Win32, about which
information is available at
http://www.cs.wisc.edu/~ghost/index.html

Hope this helps,

David C. Hoos, Sr.

Re: Gnat pretty printing

[Marin David Condic]

Matt Tyler wrote:
> 
> Hi,
> 
> Sorry if this is  slightly off topic but I couldn't find a newsgroup on
> specific compilers.
> 
> Does anyone know if it is possible for my gnat ada compiler running under
> win95 pretty print? I.e. change font or use bold type for reserved words
> etc??
> 
So far as I know, GNAT itself does not do any pretty-printing. However,
you should have the AdaGide editor available with the WinNT release and
that has a "Format" button. (I don't particularly like the style of
formatting it does, but that's a personal preference sort of thing.)
There is also something called pc-Grasp which does a nice job of
editing/pretty-printing. It was available, I think, from Auburn
University. I don't have the URL at this time, so if you find it, please
post it.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669

"Transported to a surreal landscape, a young girl kills the first woman
she meets and then teams up with three complete strangers to kill
again."

        -- TV listing for the Wizard of Oz

Re: Gnat pretty printing

[Tom Moran]

There's a very nice web program at
http://www.cs.purdue.edu/homes/young/software/c2html.html
that takes Ada source and sends you back nice HTML.  I think it's a
demo version of a bigger thing.

Re: Gnat pretty printing

[dennison]

In article <366ec076.287075@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> There's a very nice web program at
> http://www.cs.purdue.edu/homes/young/software/c2html.html

Is it me, or is that link dead?

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Gnat pretty printing

[David C. Hoos]

Marin David Condic wrote in message <366E9E44.AA7370C7@pwfl.com>...
<snip>
>There is also something called pc-Grasp which does a nice job of
>editing/pretty-printing. It was available, I think, from Auburn
>University. I don't have the URL at this time, so if you find it, please
>post it.
>
It's at:
http://www.eng.auburn.edu/department/cse/research/grasp/grasp.html



David C. Hoos, Sr.

Re: Gnat pretty printing

[Tom Moran]

>> There's a very nice web program at
>> http://www.cs.purdue.edu/homes/young/software/c2html.html

>Is it me, or is that link dead?
Oops, it looks dead to me too.  It was quite nice when it was there.
Anyone up for a little searching?

Re: Gnat pretty printing

[Martin C. Carlisle]

In article <366E9E44.AA7370C7@pwfl.com>,
Marin David Condic  <diespammer@pwfl.com> wrote:
>> Does anyone know if it is possible for my gnat ada compiler running under
>> win95 pretty print? I.e. change font or use bold type for reserved words
>> etc??
>> 
>So far as I know, GNAT itself does not do any pretty-printing. However,
>you should have the AdaGide editor available with the WinNT release and
>that has a "Format" button. (I don't particularly like the style of
>formatting it does, but that's a personal preference sort of thing.)
>There is also something called pc-Grasp which does a nice job of
>editing/pretty-printing. It was available, I think, from Auburn
>University. I don't have the URL at this time, so if you find it, please
>post it.

As it turns out, I have an independent study project slated for next semester
to reimplement the reformatting tool in AdaGIDE.  It is also available as
a standalone tool, and will generate colorized RTF output.  Suggestions for 
requirements are welcome, although I don't promise to have the same 
preferences you do :-).  Send these to mcc@cs.usafa.af.mil

AdaGIDE is distributed with GNAT on Windows, beginning with version 3.10p,
but the latest AdaGIDE is found at 
http://www.usafa.af.mil/dfcs/bios/mcc_html/adagide.html

The reformatter standalone is at: 
http://www.usafa.af.mil/dfcs/bios/mcc_html/ada_stuff.html

Of course, the best way to implement such a tool would be with ASIS rather
than modifying the sources of GNAT.  We will NOT take this approach, however,
because it is essential in our environment to be able to reformat code that
will not compile, on a "as you go" basis during editing.

--Martin

-- 
Martin C. Carlisle, Computer Science, US Air Force Academy
mcc@cs.usafa.af.mil, http://www.usafa.af.mil/dfcs/bios/carlisle.html
DISCLAIMER:  This content in no way reflects the opinions, standard or 
policy of the US Air Force Academy or the United States Government.

Re: Gnat pretty printing

[okellogg]

In article <366E86FF.64933A71@lmco.com>,
  Steve O'Neill <steven.m.oneill@lmco.com> wrote:
>
> Well GNAT the compiler doesn't do this (nor would I expect it to).

This is one GNAT feature I had been toying around implementing
but haven't got around to doing. It's certainly not difficult to do this.
In previous versions of GNAT there was some option that
reproduced the source from the internal syntax tree. The only thing
to do would have been, adjust identifier capitalization and preserve
comments.

-- Oliver

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Gnat pretty printing

[dewarr]

In article <74oa8h$2dj$1@nnrp1.dejanews.com>,
  okellogg@my-dejanews.com wrote:
> In article <366E86FF.64933A71@lmco.com>,
>   Steve O'Neill <steven.m.oneill@lmco.com> wrote:
> >
> > Well GNAT the compiler doesn't do this (nor would I
expect it to).
>
> This is one GNAT feature I had been toying around
implementing
> but haven't got around to doing. It's certainly not
difficult to do this.
> In previous versions of GNAT there was some option that
> reproduced the source from the internal syntax tree. The
only thing
> to do would have been, adjust identifier capitalization
and preserve
> comments.
>
> -- Oliver
>
> -----------== Posted via Deja News, The Discussion
Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or
Start Your Own
>

This is not quite so simple, this approach would lose
the comments. There is no simple way to avoid this. I
think it would be better to use a separate tool, e.g.
build on emacs.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Gnat pretty printing

[Michael F Brenner]

Martin > ... I have an independent study project slated for next semester
       > to reimplement the reformatting tool in AdaGIDE. It is also 
       > available as a standalone tool, and will generate colorized 
       > RTF output. Suggestions for requirements are welcome, although 
       > I don't promise to have the same preferences you do :-). 

It is okay to have different preferences, it is just not okay to 
force others into using our preferences. 

Here are the requirements for a pretty printer:
  (a) There should be the option to uncapitalize all reserved words 
      and all identifiers.
  (b) There should be the option to uncaptitalize all reserved words
      but let identifiers have consistently the case they had the 
      first time they appeared.
  (c) The semantics (object code generated) should not be modified.
  (d) The comments should still be associated in some way with
      the line on which they originated.
  (e) There should be the option to align terminating comments
      with their indentation after a given column.
  (f) There should be the option to align block comments
      with their indentation after a given column, for example, 81.
  (g) There should be the option to put things with or without arrows
      underneath each other (actual arguments, formal parameters,
      array constants, etc.) in one, two, three, or four columns.
      However, if they fit on one line, they should be put on one line.
      This transition from columnated to single-lined is important.
  (h) It should append onto a statistical file the following counts: 
      (A) loops without an invariant condition comment, 
      (B) loops without a precondition comment, 
      (C) loops without a postcondition comment, 
      (D) calls to procedures named assert, 
      (E) executable lines of code counted statically,
      (F) executable lines of code including generic expansions,
      (G) executable lines of code including generics and WITHed packages,   
      (H) executable lines of code including generics, and transitive WITHs,
      (I) test paths including goto statements and exception raising,
      (J) uses of multiple entries: in Ada this means gotos and unit pointers,
      (K) non-standard PRAGMAs,
      (L) type names that are not plural noun phrases,
      (M) functions that are not singluar noun phrases,
      (N) boolean variables or functions that are not predicate phrases,
      (O) archaic loops that use WHILE instead of EXIT,
      (P) unused WITHs,
      (Q) USE statements outside a package that could have been inside.
  (i) There should be the option to append onto a statistical file
      the following counts:
      (A) highly global references (outside the compilation unit), 
      (B) global references (outside the body not incl formal parameters),
      (C) semi-global references (static to the body not incl formal parms), 
      (D) local references, 
      (E) references to pointers of any kind,
      (F) calls to procedures named assert,
      (G) results of memory leakage analysis,
      (H) variables that could have been more local without semantic change,
  (j) There should be the option to do a radiation compile, which assumes
      that either radiation struck a memory chip violating a previously
      checked constraint or else there is a compiler bug; thus, every
      time any operator is used, or any compilation unit invoked, every
      variable in every actual argument is constraint checked regardless
      of the theorems already proved by the optimizer or code generator
      that those variables are definitely already within constraints.
  (k) Color RTF output is great because it can be converted to latex,
      eroff, or sloppy html; an immediate student project, however, should
      be to convert it to XML with VML annotations, because XML is rapidly
      increasing in importance to an Air Force whose applications are
      making ever more use of web technology, and VML is the only
      proposed way of making box diagrams in the context of a web
      typesetting language.
  (l) There should be an option for all statements referencing nonlocal
      variables and all statements causing a package to be non-pure
      to be typeset in bold (alternatively, to be colored dark red).
  (m) There should be the option to replace all numbers and strings
      outside the elaboration section, except 0 and 1, with named constants.
  (n) Pretty printing rules for newlines and indenting should be 
      overridden automatically when the whole thing fits on one line
      between the code starting column and the comment starting column.
  (o) It goes without saying that 
      (A) THEN goes on the same line as the IF when it fits;
      (B) IS goes on the same line as CASE when it fits;
      (C) IF, ELSIF, ELSE, and END IF are in the same column;
      (D) CASE, WHEN, and END CASE are in the same column; 
      (E) There is NEVER a space before a colon, semicolon, comma, or period;
      (F) There is an optional space before and after assignment operators;
      (G) the capitalization for IDs and keywords should default to NOT;
      (H) PROCEDURE, BEGIN, EXCEPTION, END are in the same column;
      (I) Assignment operators and other words like renames, etc., when 
          aesthetically pleasing, should be aligned, and it would be
          challenging to define aethetical here.
  (p) An option to substitute one name for another, with semantic correctness.
  (q) An option to list any WITHs that could have been move to separates.
  (r) Identify USE statements that could have been put later.

Re: Gnat pretty printing

[Stephane Barbey]

IMHO, requiremetnts h, i, j, l and m  may be nice to have but are out of
scope for
a pretty-printer (which should neither be a style checker, nor a
programming-in-
the-large code management system).

An option I would like to find in a pretty-printer is the ability to give a
list of words,
or partial words, the case of which should not be changed. (I just hate it
when
Text_IO becomes Text_Io).

-Stephane
----
Stephane Barbey, PhD            phone: +41(31)828.92.17
Paranor AG                                fax:   +41(31)828.92.99
3046 Wahlendorf                      stephane@paranor.ch
Switzerland                                http://lglwww.epfl.ch/~barbey

Re: Gnat pretty printing

[Bob Collins]

In article <74r7ip$t1@top.mitre.org>, mfb@mbunix.mitre.org (Michael F
Brenner) wrote:

> [Material snipped.]

> Here are the requirements for a pretty printer:

> [Material snipped.]

>   (o) It goes without saying that 
>       (A) THEN goes on the same line as the IF when it fits;
>       (B) IS goes on the same line as CASE when it fits;
>       (C) IF, ELSIF, ELSE, and END IF are in the same column;
>       (D) CASE, WHEN, and END CASE are in the same column;

My LRM says that "the syntax rules describing structured constructs
are presented in a form that corresponds to the recommended
paragraphing." [1.1.4 (19)] The grammar for a case statement
indicates WHEN should be indented. That seems to indicate that
"It goes without saying" is a bit too extreme.

>       (E) There is NEVER a space before a colon, semicolon, comma, or period;

The Ada Style Guide recommends a space before a colon.

>       (F) There is an optional space before and after assignment operators;
>       (G) the capitalization for IDs and keywords should default to NOT;

This seems contrary to two fairly common practices
   reserved words are uppercased (GMU group)
   each subunit of identifiers is capitalized (NYU group)

> [Material snipped.]

Indeed, the Ada95 Style Guide
   <http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/95style>
has many automation hints, and would be a good source for deciding
how to pretty-print.

-- 
Bob Collins  <mailto:collins@cs.wm.edu>  <http://ratbert.cs.wm.edu>

Re: Gnat pretty printing

[Marin David Condic]

> 
> As it turns out, I have an independent study project slated for next semester
> to reimplement the reformatting tool in AdaGIDE.  It is also available as
> a standalone tool, and will generate colorized RTF output.  Suggestions for
> requirements are welcome, although I don't promise to have the same
> preferences you do :-).  Send these to mcc@cs.usafa.af.mil
> 
> AdaGIDE is distributed with GNAT on Windows, beginning with version 3.10p,
> but the latest AdaGIDE is found at
> http://www.usafa.af.mil/dfcs/bios/mcc_html/adagide.html
> 
> The reformatter standalone is at:
> http://www.usafa.af.mil/dfcs/bios/mcc_html/ada_stuff.html
> 
> Of course, the best way to implement such a tool would be with ASIS rather
> than modifying the sources of GNAT.  We will NOT take this approach, however,
> because it is essential in our environment to be able to reformat code that
> will not compile, on a "as you go" basis during editing.
> 
For the record, the thing I typically dislike about pretty-printers is
that I like to span certain things across lines and want them to line up
in a predictable way. Formal parameter lists on procedure declarations
and named associations on procedure calls are the two most common areas
where I'd like spanned lines and tabs to make things line up. I don't
think I could write a formal requirements document for you in just a
couple of minutes, but here's an example of some code as I manually
format it:

    procedure Pop (
        Item            :    out Element_Ptr_Type ;
        List            : in out List_Type) is
        --
        Temp            : Link_Type         := null ;
    begin
        pragma Debug (
            Ada.Text_IO.Put_Line (
                File    => Ada.Text_IO.Current_Error,
                Item    => "UTIL.Tagged_Lists.Pop: ")) ;
        if (List.Length <= 0) then
            raise Underflow ;
        end if ;
        Temp            := List.First ;
        --
        List.First      := List.First.Next ;
        List.Current    := List.First ;
        List.Length     := List.Length - 1 ;
        List.Memory     := List.Memory -
            ((Temp.all'Size / System.Storage_Unit) +
                (Temp.Value.all'Size / System.Storage_Unit)) ;
        if (List.First = null) then
            --
            --  Empty list.
            --
            List.Last       := null ;
        end if ;
        --
        Item    := Temp.Value ;
        Dispose (
            X	=> Temp) ;
    exception
        when Storage_Error =>
            pragma Debug (
                Ada.Text_IO.Put_Line (
                    File    => Ada.Text_IO.Current_Error,
                    Item    => "UTIL.Tagged_Lists.Pop: Storage_Error."))
;
            raise Underflow ;
        when Constraint_Error =>
            pragma Debug (
                Ada.Text_IO.Put_Line (
                    File    => Ada.Text_IO.Current_Error,
                    Item    => "UTIL.Tagged_Lists.Pop:
Constraint_Error.")) ;
            raise Underflow ;
    end Pop ;


Notice specifically how the formal parameter list in/out, etc line up
with each parameter on a separate line. Also the procedure calls with
named association and the assignment statements with the := lining up. I
am not too terribly concerned about the capitalization/lower-case issues
since this is usually a toggleable option and you have to modify the
capitalization anyway for abbreviations. The main thing about my
formatting style is that it is extremely regular & predictable with a
visually pleasing alignment of related objects. I'm not sure it is
possible to codify all of the style into a program that would produce
the desired result in all cases, but even if it just got me close, I'd
be willing to patch it up manually when I considered the jobe done.

I hope this might give you a few good ideas. If you want to talk over
any ideas I'd be glad to help if I can.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Transported to a surreal landscape, a young girl kills the first woman
she meets and then teams up with three complete strangers to kill
again."

        -- TV listing for the Wizard of Oz

Re: Gnat pretty printing

[dewarr]

In article <74r7ip$t1@top.mitre.org>,
  mfb@mbunix.mitre.org (Michael F Brenner) wrote:
> Here are the requirements for a pretty printer:

Don't you mean "my" requirements, rather than "the"
requirements?

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Gnat pretty printing

[Bryce Bardin]

Michael F Brenner wrote:
  (snip)
> Here are the requirements for a pretty printer:
>   (a) There should be the option to uncapitalize all reserved words
>       and all identifiers.
>   (b) There should be the option to uncaptitalize all reserved words
>       but let identifiers have consistently the case they had the
>       first time they appeared.
  (snip)

We wrote one at Hughes in the 80's that had capitalization control
based on switches and which supported fixed capitalization of either a
default or project-specific set of acronyms.  However, very few
projects used it.  They just couldn't be bothered.  Style was either
enforced by the rest of the toolset (� la Rational) or manually checked
during code reviews.

>   (h) It should append onto a statistical file the following counts: 
  (snip)

Statistics should be collected by a separate, tailorable tool, IMHO.
The tool we wrote at Hughes *was* used extensively.

Re: Gnat pretty printing

[Robert A Duff]

Marin David Condic <condicma@bogon.pwfl.com> writes:

>     procedure Pop (
>         Item            :    out Element_Ptr_Type ;
>         List            : in out List_Type) is
>         --
>         Temp            : Link_Type         := null ;

Why do you like the colon after Temp to line up with the colons in the
parameter list?  Temp is local, and has nothing to do with the
parameters, so why make it look similar?  And why should the ":= null"
line up with the "is"?

>     begin
>         pragma Debug (
>             Ada.Text_IO.Put_Line (
>                 File    => Ada.Text_IO.Current_Error,
>                 Item    => "UTIL.Tagged_Lists.Pop: ")) ;
>         if (List.Length <= 0) then
>             raise Underflow ;
>         end if ;
>         Temp            := List.First ;
>         --
>         List.First      := List.First.Next ;
>         List.Current    := List.First ;
>         List.Length     := List.Length - 1 ;
>         List.Memory     := List.Memory -

And why do all these ":=" line up?

>             ((Temp.all'Size / System.Storage_Unit) +
>                 (Temp.Value.all'Size / System.Storage_Unit)) ;
>         if (List.First = null) then
>             --
>             --  Empty list.
>             --
>             List.Last       := null ;

What's the purpose of the extra space there?

>         end if ;
>         --
>         Item    := Temp.Value ;
>         Dispose (
>             X	=> Temp) ;

Why two lines for the Dispose?

>     exception
>         when Storage_Error =>
>             pragma Debug (
>                 Ada.Text_IO.Put_Line (
>                     File    => Ada.Text_IO.Current_Error,
>                     Item    => "UTIL.Tagged_Lists.Pop: Storage_Error."))
> ;

And why extra space there?  And why ";" on the next line?
Maybe that's just an accident of posting software.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Gnat pretty printing

[Simon Wright]

Marin David Condic <condicma@bogon.pwfl.com> writes:

[..]
>     procedure Pop (
>         Item            :    out Element_Ptr_Type ;
>         List            : in out List_Type) is
[..]
> formatting style is that it is extremely regular & predictable with a
> visually pleasing alignment of related objects. I'm not sure it is
[..]

I don't think we shall ever agree on that style! The dangling ( after
Pop is my pet hate, I fear. Customisability is the best bet ..

I wrote a formatter once that allowed you to mingle formatting options
with syntax specifications, but (a) it was written in a special parser
generator which (b) targetted VMS LIB$TPARSE and (c) required
single-trackability in the grammar+options (not sure of the technical
term for that). The grammar part would have been OK, I think, but the
options were the killer .. perhaps there are programming systems in
which this sort of thing would be simple?

Re: Gnat pretty printing

[Ehud Lamm]

I'll add my view on this.

On Sat, 12 Dec 1998, Robert A Duff wrote:

> Marin David Condic <condicma@bogon.pwfl.com> writes:
> >         List.First      := List.First.Next ;
> >         List.Current    := List.First ;
> >         List.Length     := List.Length - 1 ;
> >         List.Memory     := List.Memory -
> 
> And why do all these ":=" line up?

I like this style too. It is easier to read (for me at least) when the :=
line up.

> >   exception
> >         when Storage_Error =>
> >             pragma Debug (
> >                 Ada.Text_IO.Put_Line (
> >                     File    => Ada.Text_IO.Current_Error,
> >                     Item    => "UTIL.Tagged_Lists.Pop: Storage_Error."))

I prefer that the => line up. The spacing before is not important for me.

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il

Re: Gnat pretty printing

[dennison]

In article <x7v3e6lu3eh.fsf@pogner.demon.co.uk>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:
> Marin David Condic <condicma@bogon.pwfl.com> writes:
>
> >     procedure Pop (
> >         Item            :    out Element_Ptr_Type ;

> I don't think we shall ever agree on that style! The dangling ( after
> Pop is my pet hate, I fear. Customisability is the best bet ..

Personally, I prefer to put the '(' in front of "Item" like you, but I like to
leave a dangling ')' to line up with the ')'.  :-)


--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Gnat pretty printing

[Robert I. Eachus]

In article <74on70$m9o$1@cnn.Princeton.EDU> mcc@tyrolia.cs.princeton.edu (Martin C. Carlisle) writes:

 > As it turns out, I have an independent study project slated for
 > next semester to reimplement the reformatting tool in AdaGIDE.  It
 > is also available as a standalone tool, and will generate colorized
 > RTF output.  Suggestions for requirements are welcome, although I
 > don't promise to have the same preferences you do...

   One thing that would be VERY handy would be the ability to match
 -gnatg rules.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Gnat pretty printing

[dennison]

In article <36768419.79B1F29A@pwfl.com>,
  diespammer@pwfl.com (MDC) wrote:

> I used to hate the dangling "(" too. But I've grown to like it. The
> reason is that sticking the "(" with the first parameter seems to upset
> the regularness of it all. Somehow, it makes the first parameter
> different from the rest and I never could tell if it made sense to line
> up the parameter names or just indent the same amount:
>
> procedure Pop
>     (Item      :    out Element_Type ;
>     List       : in out List_Type) ;
>
> vs
>
> procedure Pop
>    (Item       :    out Element_Type ;
>     List       : in out List_Type) ;

You could do what some of my anal-retentive (and english-imparied) coworkers
took to doing: line up your commas or semicolons in the parameter lists with
the parentheses! eg:

  procedure Pop
    ( Item :    out Element_Type
    ; List : in out List_Type
    ; Flag : in     Boolean
    ) ;

Another advantage of this that they touted is that a parameter may be added or
deleted at the w/o having to worry about dealing with the "no comma after the
last parameter" rule.

I was always quick to point out that they just moved the problem to the first
parameter, and that it is very un-english like. But their overly mathematical
minds just didn't care.

What I actually prefer myself is the same as above, but with the semicolons
where you'd expect them to be.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Gnat pretty printing

[Matthew Heaney]

Marin David Condic <condicma@bogon.pwfl.com> writes:

> I used to hate the dangling "(" too. But I've grown to like it. The
> reason is that sticking the "(" with the first parameter seems to upset
> the regularness of it all. Somehow, it makes the first parameter
> different from the rest and I never could tell if it made sense to line
> up the parameter names or just indent the same amount:
> 
> procedure Pop
>     (Item      :    out Element_Type ;
>     List       : in out List_Type) ;
> 
> vs
> 
> procedure Pop
>    (Item       :    out Element_Type ;
>     List       : in out List_Type) ;
> 
> Either way, it just didn't seem comfortable - so I learned to like the
> dangling "(".
> 
> I'm sure we are touching off a religious war here. I will no doubt get
> dozens of people out there foaming at the mouth over just how morally
> evil the dangling "(" is. Oh well. I doubt if we could ever get the
> whole world to agree on a formatting standard in all its details. Maybe
> we just have to have enough of a consensus over the bigger things such
> that Ada code has enough regularity to it to be easily recognizable.
> (The character case debate seems to have been mostly settled, so maybe
> there's hope for parameter lists?)


If you use ada-mode with emacs, then this is a non-issue.  The open
paren goes where you expect it (see below), and it can format the entire
parameter list (C-c C-f), even getting rid of that nasty space that
preceeds the semicolons.  

procedure Pop
  (Item :    out Element_Type;
   List : in out List_Type);


I live by these words:

"Get a life.  Get emacs."  

Life is good...

Re: Gnat pretty printing

[Marin David Condic]

Matthew Heaney wrote:
> 
> 
> If you use ada-mode with emacs, then this is a non-issue.  The open
> paren goes where you expect it (see below), and it can format the entire
> parameter list (C-c C-f), even getting rid of that nasty space that
> preceeds the semicolons.
> 
> procedure Pop
>   (Item :    out Element_Type;
>    List : in out List_Type);

I think you missed my point. Which was: I don't like that particular
style. It somehow makes the first parameter look like a special case and
I can never make up my mind if I like the names aligned or the
paren/names aligned. That's why I learned to like the dangling "("

See?!?! The religious wars are starting!

> 
> I live by these words:
> 
> "Get a life.  Get emacs."
> 
> Life is good...

I've had a life. I've also had emacs. I've found both to be overrated.
:-)

I think I prefer some of the older style editors - like TPU. (Let's not
get started on things like TECO or SOS.) Maybe it's just what you're
used to.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Eagles may soar, but a weasle never gets sucked up into a jet engine."

        --  Author Unknown

Re: Gnat pretty printing

[Marin David Condic]

dennison@telepath.com wrote:
> 
> You could do what some of my anal-retentive (and english-imparied) coworkers
> took to doing: line up your commas or semicolons in the parameter lists with
> the parentheses! eg:
> 
>   procedure Pop
>     ( Item :    out Element_Type
>     ; List : in out List_Type
>     ; Flag : in     Boolean
>     ) ;
> 

That is a style which had not occurred to me. I guess it has the
advantage that each parameter starts in the same column, but it really
disturbs my eye that the terminating semicolon isn't after the thing it
terminates.

Maybe I could get used to it, but it would take time and possibly
chemical restraints.

> Another advantage of this that they touted is that a parameter may be added or
> deleted at the w/o having to worry about dealing with the "no comma after the
> last parameter" rule.
> 
> I was always quick to point out that they just moved the problem to the first
> parameter, and that it is very un-english like. But their overly mathematical
> minds just didn't care.
> 
Well, I don't know that a formatting style is going to keep you from
making syntax errors. The only excuse I can see for it is ease of
reading. I'd have to agree it only shifts the problem.

> What I actually prefer myself is the same as above, but with the semicolons
> where you'd expect them to be.
> 
Ahhhh, but then you've got two levels of indent! The level where the
parens occur, then the level where the parameters occur. It just doesn't
seem logical.

But as I said earlier, I doubt we are ever going to get total agreement
on formatting, but so long as it is neat we could probably tolerate the
differences.

I take it that for the most part, we could agree that the parameters
should occur on separate lines, that the colons line up and that the "in
out", "in     " and "   out" should all occupy the same amount of space
so that the type names line up. Or would that be presumptuous of me?
(Allowing for the fact that, like most style rules, there are always a
few exceptions where it makes sense to do something else...)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Eagles may soar, but a weasle never gets sucked up into a jet engine."

        --  Author Unknown

Re: Gnat pretty printing

[Marin David Condic]

Robert A Duff wrote:
> 
> Marin David Condic <condicma@bogon.pwfl.com> writes:
> 
> >     procedure Pop (
> >         Item            :    out Element_Ptr_Type ;
> >         List            : in out List_Type) is
> >         --
> >         Temp            : Link_Type         := null ;
> 
> Why do you like the colon after Temp to line up with the colons in the
> parameter list?  Temp is local, and has nothing to do with the
> parameters, so why make it look similar?  And why should the ":= null"
> line up with the "is"?
> 
<snip>
> 
> And why do all these ":=" line up?
> 
<snip>
> 
> What's the purpose of the extra space there?
> 
<snip>
> 
> Why two lines for the Dispose?
> 
<snip>
> 
> And why extra space there?  And why ";" on the next line?
> Maybe that's just an accident of posting software.
> 
I suppose there's no easier way to start a religious debate than to say
"I like this formatting style..." :-)

Why? Why does everything line up? Well, I use the tab key a lot and for
some reason it fits my obsessive-compulsive personality to see
everything line up. I just find it graphically attractive to see all the
formals on one side of a line and actuals on the other, or object names
on one side of the line, types on the other, etc. And if you look at the
code as I format it, you'll see that it is very regular - things are
done the same way every time. Parameter associations are always named,
the fingers (=>) all line up, etc. etc.

I suppose when you get down to it, I can't give you some kind of
rational, technical "why" answer to this. It's a style I evolved over a
long period of time, sometimes adapting what I've seen other people do,
sometimes deriving the style from what seemed to make sense to me from
the syntax/semantics of the language. I find it easy on the eyes and
rigorous enough to keep my code from looking organically grown. Most
people who have had to play around in my code have found it easy to
understand and easy to maintain. (I've had a number of comments about
how nice it is that all the parameter passing is done with named
notation, rather than positional. I'll leave it to the language
theoreticians to go debate why that is.)

I'm sure you have a style you prefer and no doubt it is different than
mine. Does it accomplish the same end? All I hope to do is keep the code
looking tidy (like good penmanship) and make it as clear as I can as to
what is going on. Other styles may accomplish the same goals. Maybe you
could post an example of what your style looks like? I'm sure there are
elements of it which I and others may like to adopt.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Eagles may soar, but a weasle never gets sucked up into a jet engine."

        --  Author Unknown

Re: Gnat pretty printing

[Marin David Condic]

Simon Wright wrote:
> 
> Marin David Condic <condicma@bogon.pwfl.com> writes:
> 
> [..]
> >     procedure Pop (
> >         Item            :    out Element_Ptr_Type ;
> >         List            : in out List_Type) is
> [..]
> > formatting style is that it is extremely regular & predictable with a
> > visually pleasing alignment of related objects. I'm not sure it is
> [..]
> 
> I don't think we shall ever agree on that style! The dangling ( after
> Pop is my pet hate, I fear. Customisability is the best bet ..
> 
I used to hate the dangling "(" too. But I've grown to like it. The
reason is that sticking the "(" with the first parameter seems to upset
the regularness of it all. Somehow, it makes the first parameter
different from the rest and I never could tell if it made sense to line
up the parameter names or just indent the same amount:

procedure Pop
    (Item      :    out Element_Type ;
    List       : in out List_Type) ;

vs

procedure Pop
   (Item       :    out Element_Type ;
    List       : in out List_Type) ;

Either way, it just didn't seem comfortable - so I learned to like the
dangling "(".

I'm sure we are touching off a religious war here. I will no doubt get
dozens of people out there foaming at the mouth over just how morally
evil the dangling "(" is. Oh well. I doubt if we could ever get the
whole world to agree on a formatting standard in all its details. Maybe
we just have to have enough of a consensus over the bigger things such
that Ada code has enough regularity to it to be easily recognizable.
(The character case debate seems to have been mostly settled, so maybe
there's hope for parameter lists?)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Eagles may soar, but a weasle never gets sucked up into a jet engine."

        --  Author Unknown

Re: Gnat pretty printing

[Matthew Heaney]

Marin David Condic <condicma@bogon.pwfl.com> writes:

> I take it that for the most part, we could agree that the parameters
> should occur on separate lines, that the colons line up and that the "in
> out", "in     " and "   out" should all occupy the same amount of space
> so that the type names line up. Or would that be presumptuous of me?
> (Allowing for the fact that, like most style rules, there are always a
> few exceptions where it makes sense to do something else...)

Just type "C-c C-f", and life is good...

Re: Gnat pretty printing

[dennison]

In article <3676DF28.8C0C3C3A@pwfl.com>,
  diespammer@pwfl.com wrote:
> dennison@telepath.com wrote:
> >
> > You could do what some of my anal-retentive (and english-imparied) coworkers
> > took to doing: line up your commas or semicolons in the parameter lists with
> > the parentheses! eg:
> >
> >   procedure Pop
> >     ( Item :    out Element_Type
> >     ; List : in out List_Type
> >     ; Flag : in     Boolean
> >     ) ;
> >
>
> That is a style which had not occurred to me. I guess it has the
> advantage that each parameter starts in the same column, but it really
> disturbs my eye that the terminating semicolon isn't after the thing it
> terminates.
>
> Maybe I could get used to it, but it would take time and possibly
> chemical restraints.

I'm glad I'm not the only one. That actually got codified as our "official"
style on one project. Yuk.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Gnat pretty printing

[Matthew Heaney]

By using ada-mode with emacs, there is no justification for
idiosyncratic coding conventions like that one described below.


dennison@telepath.com writes:

> In article <3676DF28.8C0C3C3A@pwfl.com>,
>   diespammer@pwfl.com wrote:
> > dennison@telepath.com wrote:
> > >
> > > You could do what some of my anal-retentive (and english-imparied) coworkers
> > > took to doing: line up your commas or semicolons in the parameter lists with
> > > the parentheses! eg:
> > >
> > >   procedure Pop
> > >     ( Item :    out Element_Type
> > >     ; List : in out List_Type
> > >     ; Flag : in     Boolean
> > >     ) ;
> > >
> >
> > That is a style which had not occurred to me. I guess it has the
> > advantage that each parameter starts in the same column, but it really
> > disturbs my eye that the terminating semicolon isn't after the thing it
> > terminates.
> >
> > Maybe I could get used to it, but it would take time and possibly
> > chemical restraints.
> 
> I'm glad I'm not the only one. That actually got codified as our "official"
> style on one project. Yuk.
> 
> --
> T.E.D.
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Gnat pretty printing

[Chris Morgan]

dennison@telepath.com writes:

> > Maybe I could get used to it, but it would take time and possibly
> > chemical restraints.
> 
> I'm glad I'm not the only one. That actually got codified as our "official"
> style on one project. Yuk.

The GNAT coding style is pretty much my favourite, and there's a
switch which enforces it (although it's not a supported use of the
compiler). When Prof Dewar finally writes his "everything you always
wanted to know about Ada that you never found in any of the other
books" tome I hope he states the style rules he works to. To me
reading the GNAT source code is a bit like reading a really good
O'Reilly book, part of the pleasure is just in the layout.

Chris

-- 
Chris Morgan <mihalis at ix.netcom.com>		http://www.mihalis.net
	         "At least my mother isn't on the 
                  cover of Crack Whore magazine"

Re: Gnat pretty printing

[Dale Stanbrough]

Mr dennison@telepath.com wrote:

 > >   procedure Pop
 > >     ( Item :    out Element_Type
 > >     ; List : in out List_Type
 > >     ; Flag : in     Boolean
 > >     ) ;
 > >
 >
 > That is a style which had not occurred to me. I guess it has the
 > advantage that each parameter starts in the same column, but it really
 > disturbs my eye that the terminating semicolon isn't after the thing it
 > terminates.


They are not terminating semicolons (the last one in the list -doesn't-
have one) - they are separating semicolons. It is more consistent, but
it still doesn't follow that it is easy to read. I suspect that our use
of semicolons in natural languages makes it use at the start of a line 
always seem a bit suspect.

Dale

Re: Gnat pretty printing

[dewar]

In article <87ogp4oyx8.fsf@mihalis.ix.netcom.com>,
  Chris Morgan <mihalis@ix.netcom.com> wrote:
> The GNAT coding style is pretty much my favourite, and
> there's a
> switch which enforces it (although it's not a supported
> use of the
> compiler). When Prof Dewar finally writes his "everything
> you always
> wanted to know about Ada that you never found in any of
> the other
> books" tome I hope he states the style rules he works to.
> To me
> reading the GNAT source code is a bit like reading a
> really good
> O'Reilly book, part of the pleasure is just in the
> layout.
>
> Chris


Thankyou Chris for those nice words. I just wanted to let
people know that in response to several requests, we are
now implementing the style checking in GNAT as a first
class citizen. This will provide selectable control over
all aspects of style checking now checked by the -gnatg
switch, as well as the ability to parametrize indentation
level and maximum line length checks.

Robert Dewar
Ada Core Technologies

P.S. One of the advantages of the Open Source Systems model
for software is that you know your work will be read by a
potentially wide audience, and it makes it more worthwhile
to put in the effort to make it beautiful and readable :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Gnat pretty printing

[Lieven Marchand]

Marin David Condic <condicma@bogon.pwfl.com> writes:

> I've had a life. I've also had emacs. I've found both to be overrated.
> :-)
> 
> I think I prefer some of the older style editors - like TPU. (Let's not
> get started on things like TECO or SOS.) Maybe it's just what you're
> used to.

Well, somebody in the emacs camp seems to agree with you. 
M-x tpu-edt-on turns on tpu emulation.

M-x all-hail-emacs
:-)
-- 
Lieven Marchand <mal@bewoner.dma.be> 
------------------------------------------------------------------------------
Few people have a talent for constructive laziness. -- Lazarus Long

Re: Gnat pretty printing

[BARDIN Marc]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

Is there any solution to print Ada source code from AdaGide with colors (as
with screen / form).
I'm currently using HP deskjet 660C.

Thanks Marc

________________________________
Martin C. Carlisle a �crit dans le message
<74on70$m9o$1@cnn.Princeton.EDU>...
>In article <366E9E44.AA7370C7@pwfl.com>,
>Marin David Condic  <diespammer@pwfl.com> wrote:
>>> Does anyone know if it is possible for my gnat ada compiler running
under
>>> win95 pretty print? I.e. change font or use bold type for reserved words
>>> etc??
>>>
>>So far as I know, GNAT itself does not do any pretty-printing. However,
>>you should have the AdaGide editor available with the WinNT release and
>>that has a "Format" button. (I don't particularly like the style of
>>formatting it does, but that's a personal preference sort of thing.)
>>There is also something called pc-Grasp which does a nice job of
>>editing/pretty-printing. It was available, I think, from Auburn
>>University. I don't have the URL at this time, so if you find it, please
>>post it.
>