comp.lang.ada
 help / color / mirror / Atom feed
From: "John G. Volan" <johnvolan@sprintmail.com>
Subject: Re: Ada95 Pretty-Printers
Date: 1997/06/12
Date: 1997-06-12T00:00:00+00:00	[thread overview]
Message-ID: <33A02793.431C@sprintmail.com> (raw)
In-Reply-To: resurrect.339DA006.228F@sprintmail.com


Weird... looks like either my newsreader or Samuel's ate up all the
whitespace in my examples.  Here's what they should have looked like
(I'm going to put the whitespace back in, and hopefully the ">" quote
characters will keep the newsreader's appetite in check. :-)

John G. Volan wrote:
> 
> Samuel Mize wrote:
> >
> > I got in the habit of putting an empty comment where I wanted a
> > line break. To use your first example:
> >
> > procedure Operation --
> >   (This  : in     This_Type; --
> >    That  : in     That_Type; --
> >    Other :    out Other_Type);
> >
> > will become something like:
> >
> > procedure Operation --
> >   (This : in This_Type; --
> >    That : in That_Type; --
> >    Other : out Other_Type);
> >
> > (Assuming that Apex doesn't maintain the blanks to line up "in"
> > and "out").
> 
> Actually, the PRESERVE_WHITESPACE switch will respect the blanks you
> manually put into a param list, but here's what Apex does with the
> above:
> 
> procedure Operation --
>             (This  : in     This_Type; --
>              That  : in     That_Type; --
>              Other :    out Other_Type);

(What you should be seeing here is:
- the parameter names all lined up against the open paren
- the colons (":") all lined up
- the "in" keywords all lined up
- the "out" keyword spaced to the right of the "in" keyword
- the type names all lined up
**BUT**
- the initial open paren indented all the way over to two spaces right
from the "O" in "Operation", *NOT* aligned on the left, indented two
spaces from the "p" in "procedure".)

> Folks, is it okay with you if I say this is just plain dumb, or do I
> have to hem and haw about it being all a matter of taste? :-)
> 
[snip]
> > I got third-hand, supposedly from someone at Rational, that if you
> > put two spaces at the end of a line, the reformatter will leave
> > that line break. If you don't want trailing comments in your code,
> > you can try it. I don't know if it's a feature they promise to
> > support, or just an artifact of the then-current implementation.
> 
> Hmm, that seems to work, but this is what you get:
> 
> procedure Operation
>             (This  : in     This_Type;
>              That  : in     That_Type;
>              Other :    out Other_Type);

(The open parent should still appear two spaces right from the "O" in
"Operation".)

> I tried this on some control structures, too. If you start with this:
> 
> if Condition
> then
>   Statement;
> elsif Condition
> then
>   Statement;
> else
>   Statement;
> end if;
> 
> case Expression is
> when Choice =>
>   Statement;
> when Choice =>
>   Statement;
> end case;
> 
> Label:
> while Condition
> loop
>   Statement;
> end loop Label;
> 
> Block_Name:
> begin
>   Statement;
> exception
> when Exception_Name =>
>   Statement;
> end Block_Name;

(What you should see above is all the reserved words lined up on the
left (including "then", "loop", and "when"), and all the Statements
indented exactly the same, two spaces, no matter which part of the
syntax they're in.)

> you wind up with:
> 
> if Condition
>   then
>   Statement;
> elsif Condition
>   then
>   Statement;
> else
>   Statement;
> end if;

(The "then" keywords are indented two spaces rather than aligned left.)

> case Expression is
>   when Choice =>
>     Statement;
>   when Choice =>
>     Statement;
> end case;

(The "when" clauses add a level of indent we don't want, so two levels
of indent have to be unrolled after the last Statement.)

> Loop_Name:
>   while Condition
>     loop
>     Statement;
>   end loop Loop_Name;

(The Loop_Name introduces an extra level of indent we don't want; and
the "loop" keyword is indented two spaces rather than aligned with the
"while".)


> Block_Name:
>   begin
>     Statement;
>   exception
>     when Exception_Name =>
>       Statement;
>   end Block_Name;

(The "when" clauses add a level of indent we don't want, so two levels
of indent have to be unrolled after the last Statement; and the
Block_Name adds a whole other level of indent.)

> (This is with INDENTATION = BREAK_INDENT = 2.)
> 
> In other words: (1) If you force a linebreak before a "then" or a
> "loop", Apex treats it as a continuation line and indents it by
> BREAK_INDENT, rather than lining it up with the "if" or "while". And (2)
> you can't prevent "when" clauses and block/loop names from introducing
> an extra indent.
> 
> Witness what Apex does to an instantiation. Using the
> double-space-before-linebreak trick, you can go from this:
> 
> procedure Deallocate is new Ada.Unchecked_Deallocation
>   (Object => Object_Type'Class,
>    Name   => Object_Access_Type);

(The open paren should be indented two spaces from the "p" in
"procedure".)

> to this:
> 
> procedure Deallocate is new Ada.Unchecked_Deallocation
>                               (Object => Object_Type'Class,
>                                Name   => Object_Access_Type);

(The open paren should now be shoved all the way over to two spaces
right of the "A" in "Ada.")

> If you try this:
> 
> procedure Deallocate is new
>   Ada.Unchecked_Deallocation
>   (Object => Object_Type'Class,
>    Name   => Object_Access_Type);

("Ada" and "(" indented two spaces from the "p" in "procedure".)

> Here's what you get:
> 
> procedure Deallocate is new
>                            Ada.Unchecked_Deallocation
>                            (Object => Object_Type'Class,
>                             Name   => Object_Access_Type);

("Ada" and "(" shoved all the way over, just to the right of "new"!)

> !!!

!!! You said it, man!  (I mean, _I_ said it, man! :-)

(Bob, Bob, Bobby, Robert and Cecil, move over!  You need to free up some
space at the funny-farm for John, John, John-John, Johnny, Juan, Jean,
Giovanni, Johannes, Ivan, Ian, Yiannis, Ioannes, Yohannan, and George,
who have all been driven batty by Apex! :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------




  parent reply	other threads:[~1997-06-12  0:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <339C58A6.4D5A@sprintmail.com>
1997-06-10  0:00 ` Ada95 Pretty-Printers Samuel Mize
1997-06-10  0:00   ` John G. Volan
1997-06-10  0:00     ` Spam Hater
1997-06-10  0:00       ` Spam Hater
1997-06-16  0:00     ` Greg Gicca @pulsar
1997-06-10  0:00   ` stuman
1997-06-10  0:00   ` John G. Volan
1997-06-11  0:00     ` Samuel Mize
1997-06-12  0:00     ` John G. Volan [this message]
1997-06-13  0:00       ` Samuel Mize
1997-06-14  0:00         ` Tom Phinney
1997-06-14  0:00         ` Robert Dewar
1997-06-14  0:00           ` Samuel Mize
1997-06-14  0:00             ` Robert Dewar
1997-06-12  0:00     ` Robert Dewar
1997-06-10  0:00 ` Anonymous
1997-06-10  0:00   ` John G. Volan
1997-06-11  0:00 ` Rolf Ebert
1997-06-11  0:00   ` John G. Volan
1997-06-11  0:00 ` Matthew Heaney
1997-06-12  0:00 ` Jeff Burns
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox